Сборник статей участников Всероссийского конкурса научных работ студентов и аспирантов «Телематика'2010: телекоммуникации, веб-технологии, суперкомпьютинг»

Министерство образования и науки Российской Федерации Российская академия наук Национальный фонд подготовки кадров

Труды XVII Всероссийской научно-методической конференции

Телематика'2010 Сборник статей участников Всероссийского конкурса научных работ студентов и аспирантов «Телематика'2010: телекоммуникации, веб-технологии, суперкомпьютинг»

21–24 июня 2010 года, Санкт-Петербург Санкт-Петербургский государственный университет информационных технологий, механики и оптики Государственный научно-исследовательский институт информационных технологий и телекоммуникаций «Информика», Москва

Сборник статей участников Всероссийского конкурса научных работ студентов и аспирантов «Телематика'2010: телекоммуникации, веб-технологии, суперкомпьютинг». – СПб: СПбГУ ИТМО, 2010. – 214 с.

В сборнике представлены работы финалистов Всероссийского конкурса научных работ студентов и аспирантов «Телематика'2010: телекоммуникации, веб-технологии, суперкомпьютинг», который проводился в рамках XVII Всероссийской научно-методической конференции «Телематика'2010» (Санкт-Петербург, 21-24 июня 2010 г.). Участники конкурса – студенты высших учебных заведений и аспиранты вузов и научных учреждений. К участию в первом (заочном) этапе конкурса было принято 87 проектов студентов и аспирантов, представляющих 38 вузов и научно-исследовательских организаций из 27 регионов России. Для участия во втором (очном) этапе конкурса отобраны 46 проектов, авторы которых приглашены к участию в конференции «Телематика'2010». Участники второго этапа подготовили расширенные описания проектов в форме научных статей, представленных в данном сборнике. Сборник включает статьи финалистов конкурса, сгруппированные по трем номинациям (секциям) конкурса (Телекоммуникации; Веб-технологии; Суперкомпьютинг), а также материалы, подготовленные к проводимой в рамках конференции школе-семинару по суперкомпьютингу. Статьи в сборнике упорядочены по городу проживания авторов в пределах каждой секции. В статьях, имеющих более одного автора, фамилии докладчиков подчеркнуты.

Редакционная коллегия: Абрамов А.Г., Бухановский А.В., Гугель Ю.В., Курмышев Н.В., Сергеев А.О., Сигалов А.В. Ответственные редакторы: Абрамов А.Г., Сергеев А.О.

УДК 001.3:061.61

© Санкт-Петербургский государственный университет информационных технологий, механики и оптики, 2010 © Государственный научно-исследовательский институт информационных технологий и телекоммуникаций (ФГУ ГНИИ ИТТ «Информика»), 2010 © Авторы, 2010

2

Труды конференции Телематика’2010

О конкурсе Первый Всероссийский конкурс научных работ студентов и аспирантов «Телематика'2010: телекоммуникации, веб-технологии, суперкомпьютинг» организован как одно из мероприятий Всероссийской научно-методической конференции «Телематика'2010» (http://tm.ifmo.ru) – ежегодной конференции, которая с 1994 года проводится в Санкт-Петербурге. Организаторы конкурса – Государственный научно-исследовательский институт информационных технологий и телекоммуникаций (ФГУ ГНИИ ИТТ «Информика») и Санкт-Петербургский государственный университет информационных технологий, механики и оптики (СПбГУ ИТМО). Информационная поддержка конкурса осуществлялась на федеральном портале «Информационно-коммуникационные технологии в образовании» (http://www.ict.edu.ru). Основные цели конкурса: • Ознакомление российской научно-педагогической общественности с разработками, выполняемыми студентами и аспирантами вузов России. • Стимулирование учащейся молодежи к научно-исследовательской деятельности по тематике ИКТ. • Организация обмена опытом и обсуждения результатов работ студентов и аспирантов с участием ведущих ученых. Участники конкурса – студенты российских высших учебных заведений и аспиранты вузов и научных учреждений. На конкурс представлялись описания результатов исследований и разработок в области ИКТ, выполненных студентами и аспирантами. Тематика конкурса связана с направлениями информационно-коммуникационных технологий, которые традиционно входят в круг вопросов, рассматриваемых на конференциях «Телематика». Работы представлялись и рассматривались по трем номинациям (секциям): 1. Телекоммуникации: инфраструктура научно-образовательных компьютерных сетей; сетевые сервисы, стандарты и протоколы; администрирование сетей; управление и мониторинг сетей передачи данных; использование протокола IPv6 в современных сетях; перспективные технологии в сетях передачи данных (MPLS, QoS,...); мобильные технологии; диагностика, защита и безопасность сетей передачи данных; сетевые научные и образовательные приложения. 2. Веб-технологии: протоколы и стандарты, веб-сервисы, Web2.0, системы реального времени, системы управления информацией, корпоративные информационные, геоинформационные и интеллектуальные системы. 3. Суперкомпьютинг: параллельные алгоритмы решения сложных вычислительных задач, инструментальные средства и среды для разработки параллельных программ, прикладные программные системы параллельных вычислений, анализ и оценка эффективности параллельных алгоритмов и программ, высокопроизводительные проблемноориентированные комплексы и среды компьютерного моделирования, перспективные программно-аппаратные параллельные вычислительные архитектуры, технологии распределенных вычислений и Грид. В состав жюри конкурса вошли преподаватели и научные сотрудники из ведущих российских университетов и научно-исследовательских организаций. Сопредседатели жюри по секциям конкурса: • Гугель Юрий Викторович, к.т.н., директор филиала ФГУ ГНИИ ИТТ «Информика» в Санкт-Петербурге (Телекоммуникации); • Курмышев Николай Васильевич, к.т.н., проректор по НИТ Новгородского государственного университета им. Ярослава Мудрого (Веб-технологии); • Бухановский Александр Валерьевич, д.т.н., профессор СПбГУ ИТМО (Суперкомпьютинг). Первый (заочный) этап конкурса проводился в марте-апреле 2010 года. Участники конкурса подавали заявки с описанием выполненной работы, которые рассматривались жюри. На конкурс было подано более 100 заявок, из которых к участию в конкурсе было принято 87 проектов студентов и аспирантов, представляющих 38 вузов и научно-исследовательских организаций из 27 регионов России. Список участников конкурса с указанием организаций и наименований представленных работ размещен на сайте конкурса http://www.ict.edu.ru/tm2010/. В номинации «Телекоммуникации» (22 работы) авторами представлены результаты исследований и разработок в области проектирования, моделирования и эксплуатации 3

компьютерных сетей. Большинство работ практически ориентированы и находят применение в университетах, в которых они выполнены. Круг интересов весьма широк: от теоретического моделирования механизмов работы компьютерной сети до практической реализации использования сетевых технологий в учебном процессе. Среди представленных на конкурс работ популярны темы, связанные с мобильными сетевыми технологиями. Существенное внимание уделено real-time приложениям в сетях передачи данных и их использованию в дистанционном обучении. И, конечно, вопросы управления, мониторинга, учета ресурсов остаются актуальными при практической работе с компьютерными сетями. Номинация «Веб-технологии» оказалась наиболее многочисленной по числу участников – к рассмотрению принято 49 работ, тематика которых охватывает широкий спектр теоретических и прикладных задач. В конкурсных работах представлены следующие направления: теоретические разработки и инструментальные средства для создания вебприложений; веб-приложения для автоматизированного анализа и управления информацией; системы дистанционного обучения; автоматизированные системы для управления учебным процессом и научно-исследовательской деятельностью в вузе; веб-приложения для решения научных и инженерных задач; разработки, связанные с использованием геоинформационных систем. Многие из проектов представляют собой завершенные разработки, внедренные в вузах, научных организациях, производственной сфере. Номинация «Суперкомпьютинг» представлена 16 работами, которые условно распределяются по двум направлениям: современные технологии высокопроизводительных вычислений и параллельное математическое обеспечение решения сложных вычислительных задач. Отдельного внимания заслуживает разнообразие используемых разными авторами параллельных вычислительных архитектур: от многоядерных систем и традиционных кластеров – до Грид-вычислителей и систем на основе графических процессоров. Это, в свою очередь, косвенно связано с общей технологической направленностью представленных на конкурс материалов, в большинстве случаев посвященных описанию конкретных программных (или даже программно-аппаратных) решений, разработанных лично или с определяющим участием конкурсантов. Для участия во втором (очном) этапе конкурса отобраны 46 проектов, авторы которых приглашены к участию в конференции «Телематика'2010». Участники второго этапа подготовили расширенные описания проектов в форме научных статей, представленных в данном сборнике и входящем в пакет материалов конференции. Электронные версии статей доступны на сайте конференции «Телематика» (http://tm.ifmo.ru). Во время конференции «Телематика'2010» (21–24 июня 2010 г.) предусмотрено проведение секционных заседаний, на которых участники второго этапа конкурса представят свои работы в форме устных докладов. По результатам очного представления работ жюри определит лауреатов конкурса, которые будут отмечены дипломами и призами от организаторов и спонсоров. Проведение конкурса поддержали: • • • • • • • •

ЗАО «Лаборатория Касперского» (http://www.kaspersky.ru) Компания Cisco Systems (http://www.cisco.ru) Компания Softline (http://www.softline.ru) Корпорация Intel (http://www.intel.ru) Корпорация Microsoft (http://www.microsoft.com/rus) Корпорация Oracle (http://www.oracle.ru) Фирма «1C» (http://www.1c.ru) Корпорация Canon (http://www.canon.ru)

Подробная информация о конкурсе (порядок проведения, участники первого и второго этапов, лауреаты конкурса) представлена на портале «ИКТ в образовании» по адресу http://www.ict.edu.ru/tm2010/.

4

Труды конференции Телематика’2010

Оглавление по городам

Город

Номера страниц, на которых начинаются статьи авторов из данного города

Барнаул

67

Бийск

72

Великий Новгород

9, 76

Владимир

153

Волгоград

80, 159

Воронеж

13, 84

Иркутск

87

Кемерово

92, 99, 164, 167

Краснодар

103

Москва

15, 106, 111, 115, 120

Новокузнецк

123

Новосибирск

20, 125, 131, 173

Оренбург Пенза

176 24, 29

Переславль-Залесский

183

Петрозаводск

135

Ростов-на-Дону

139

Самара

142

Санкт-Петербург

35, 145, 186, 192

Саратов

197

Таганрог

38

Тамбов

42, 149

Тольятти Ярославль

46, 51, 56 62 5

Оглавление Секция 1. Технологии и инфраструктура телекоммуникаций СИСТЕМА МОНИТОРИНГА КОРПОРАТИВНОЙ СЕТИ НОВГОРОДСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА.................................................................................................................................................... 9 М.П. Журавлёва РАСШИРЕНИЕ ОБЛАСТИ ПРИМЕНЕНИЯ МОБИЛЬНЫХ РАДИОКОМПЛЕКСОВ С ПОМОЩЬЮ УПРАВЛЯЕМЫХ ТИПОВ МОДУЛЯЦИИ ............................................................................................................ 13 Ю.А. Дергачев РАСШИРЕНИЕ МОДЕЛИ МНОГОПРОДУКТОВОЙ СЕТИ ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ СЕТИ ИНТЕРНЕТ-ПРОВАЙДЕРА ................................................................................................................................. 15 М.А. Хенкин СИСТЕМА ОРГАНИЗАЦИИ ЭЛЕКТРОННЫХ ЛЕКЦИЙ С ВИДЕОКОНФЕРЕНЦСВЯЗЬЮ И РАЗНОРОДНЫМ ИНТЕРАКТИВНЫМ ДЕМОНСТРАЦИОННЫМ РЯДОМ ..................................................... 20 В.В. Казаков, Г.Д. Безматерных АРХИТЕКТУРА ЭЛЕКТРОННОЙ СРЕДЫ ОБУЧЕНИЯ С ПРИМЕНЕНИЕМ ГЕТЕРОГЕННЫХ СЕТЕЙ ДЛЯ ДОСТУПА К ИНФОРМАЦИОННЫМ ОБРАЗОВАТЕЛЬНЫМ РЕСУРСАМ ..................................................... 24 А.Г. Финогеев, В.А. Маслов, А.А. Финогеев МОДЕЛИРОВАНИЕ МЕХАНИЗМОВ QOS В КОММУТАТОРАХ ETHERNET ЦВЕТНЫМИ СЕТЯМИ ПЕТРИ29 А.Л. Домнин, Е.А. Кизилов, В.А. Пушкарев РАЗРАБОТКА СИСТЕМЫ МОНИТОРИНГА КОМПЬЮТЕРНОЙ СЕТИ RUNNet............................................ 35 Г.А. Карапетян РАЗРАБОТКА АЛГОРИТМА И ПРОГРАММНЫХ СРЕДСТВ СИСТЕМЫ ПОСТРОЕНИЯ ТРЕХМЕРНОЙ ЦИФРОВОЙ КАРТЫ ВЫСОТ ПО НЕСКОЛЬКИМ ИЗОБРАЖЕНИЯМ ............................................................ 38 А.А. Скляров, С.А. Скляров СИСТЕМА ОЦЕНКИ И ПРОГНОЗИРОВАНИЯ УРОВНЯ КАЧЕСТВА ОБСЛУЖИВАНИЯ В IP-СЕТЯХ С ПРИМЕНЕНИЕМ АППАРАТА ТЕОРИИ СЛОЖНОСТИ..................................................................................... 42 В.Е. Подольский, С.С. Толстых, М.М. Дружинин ИЗМЕРЕНИЯ СЕТЕВОЙ ПОЛОСЫ ПРОПУСКАНИЯ ПО ДАННЫМ О ЗАДЕРЖКЕ ПАКЕТОВ .................... 46 Т.Г. Султанов, А.М. Сухов, Д.Ю. Полукаров ВЛИЯНИЕ ИСКАЖЕНИЙ КЛЮЧЕВЫХ КАДРОВ НА ПЕРЕДАЧУ ВИДЕО В БЕСПРОВОДНЫХ СЕТЯХ .... 51 Е.С. Сагатов, А.А. Семенов, Т.Н. Устенкова, А.М. Сухов ФУНКЦИЯ РАСПРЕДЕЛЕНИЯ ЗАДЕРЖКИ ПАКЕТОВ В ГЛОБАЛЬНОЙ СЕТИ............................................ 56 Н.Ю. Кузнецова, А.К. Первицкий, А.М. Сухов МОДИФИКАЦИЯ, МОДЕЛИРОВАНИЕ, АНАЛИЗ И ВЕРИФИКАЦИЯ ПРОТОКОЛА СЕМЕЙСТВА WIRELESS ACCESS PROTOCOL ....................................................................................................................... 62 М.М. Алексеева, Е.А. Дашкова, Д.Ю. Чалый

Секция 2. Веб-технологии ИНФОРМАЦИОННЫЙ ПОРТАЛ УЧЕБНО-МЕТОДИЧЕСКОЙ ЛИТЕРАТУРЫ НА БАЗЕ ЛОКАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ (ЛВС)..................................................................................................................... 67 Е.А. Кандрин, А.А. Кузнецов, Д.В. Андрейко, А.И. Нейфельд К ВОПРОСУ ПРОЕКТИРОВАНИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ УЧЕБНЫМ ПРОЦЕССОМ ВУЗА............................................................................................................................................. 72 О.А. Бубарева СИСТЕМА СБОРА И АНАЛИЗА СТАТИСТИКИ ОБРАЩЕНИЙ К МУЛЬТИМЕДИЙНОМУ КОНТЕНТУ ДЛЯ СИСТЕМЫ Genus Media Upshot........................................................................................................................ 76 А.А. Бегишев 6

Труды конференции Телематика’2010

РАЗРАБОТКА СЕРВЕРНОЙ ГЕОИНФОРМАЦИОННОЙ СИСТЕМЫ ПО МОДЕЛИРОВАНИЮ ДИНАМИКИ ЗОН ЗАТОПЛЕНИЯ НА ЗАДАННОМ РЕЛЬЕФЕ МЕСТНОСТИ....................................................................... 80 А.В. Хоперсков, С.С. Храпов, А.В. Писарев СИСТЕМА СПУТНИКОВОГО МОНИТОРИНГА МОБИЛЬНЫХ ОБЪЕКТОВ .................................................. 84 В.В. Котов, В.Г. Макеев, Р.В. Тихонов, О.Г. Ходяков РАЗРАБОТКА WEB-ПРИЛОЖЕНИЙ НА ОСНОВЕ ТЕХНОЛОГИИ OntoBox/Libretto................................... 87 А.А. Хенкина, М.А. Кохо АВТОМАТИЗАЦИЯ ПРОЦЕССА ОЦЕНКИ ИСПОЛНИТЕЛЬСКОЙ ДЕЯТЕЛЬНОСТИ ДЛЯ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ....................................................................................................... 92 Е.Д. Пфайф, А.М. Гудов РАЗРАБОТКА ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНОГО ПОРТАЛА ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ ДЛЯ ПРОВЕДЕНИЯ НАУЧНЫХ И ИНЖЕНЕРНЫХ РАСЧЕТОВ .......................................... 99 Н.Н. Окулов СИСТЕМА УПРАВЛЕНИЯ НАУЧНОЙ ИНФОРМАЦИЕЙ НА БАЗЕ МОДИФИЦИРОВАННОЙ ГИПЕРТЕКСТОВОЙ ТЕХНОЛОГИИ ................................................................................................................. 103 А.С. Бордычевская, М.А. Быкова, А.П. Савченко СИСТЕМА СОПРОВОЖДЕНИЯ ИГРОВОГО ОБУЧЕНИЯ.............................................................................. 106 И.С. Игнатьев ТЕКСТОВАЯ КЛАСТЕРИЗАЦИЯ АЛГОРИТМОМ ROCK................................................................................ 111 И.И. Савин СИСТЕМА ПРОФЕССИОНАЛЬНОГО ОРИЕНТИРОВАНИЯ АБИТУРИЕНТА КАК МОДУЛЬ ОБРАЗОВАТЕЛЬНОГО ПОРТАЛА ВУЗА ....................................................................................................... 115 Д.О. Федоров, В.А Ипатова, Я.Ю. Петунин ПОДХОД К ПРОБЛЕМЕ ВЫБОРА ФОРМЫ УПРАВЛЕНИЯ ИТ В ПРЕДПРИЯТИЯХ МАЛОГО И СРЕДНЕГО БИЗНЕСА....................................................................................................................................... 120 А.С. Силенин АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА СОПРОВОЖДЕНИЯ ДОВУЗОВСКОЙ ПОДГОТОВКИ УЧАЩИХСЯ.............................................................................................................................. 123 А.В. Соловьева, Ю.А. Соловьева ГРАФИЧЕСКИЕ ПРЕДСТАВЛЕНИЯ АТОМНЫХ СПЕКТРОВ И ИХ РЕАЛИЗАЦИЯ В ИНФОРМАЦИОННОЙ СИСТЕМЕ «ГРОТРИАН» ............................................................................................ 125 Г.Д. Безматерных, Д.Н. Шиманский СОЗДАНИЕ СПЕЦИАЛИЗИРОВАННОГО ИНСТРУМЕНТАЛЬНОГО ПОРТАЛА ВИРТУАЛЬНЫХ МУЗЕЕВ И НАУЧНЫХ КОЛЛЕКЦИЙ................................................................................................................................ 131 Ю.Л. Попович, М.Е. Рябченко АВТОМАТИЗИРОВАННАЯ СИСТЕМА МОНИТОРИНГА ПРОДУКТИВНОСТИ РАБОТЫ АСПИРАНТОВ 135 А.Г. Власова, О.Ю. Насадкина WEB-СРЕДА РАЗРАБОТКИ PascalABC.NET ................................................................................................. 139 Ю.В. Белякова, С.С. Михалкович WEB-СЕРВИС АВТОМАТИЗАЦИИ ВЫЧИСЛЕНИЯ МАТЕМАТИЧЕСКИХ МОДЕЛЕЙ................................ 142 А.В. Камынин КОМПЬЮТЕРНАЯ ПОДДЕРЖКА МОНИТОРИНГА ИНДИВИДУАЛЬНЫХ ДОСТИЖЕНИЙ СТУДЕНТА НА УРОВНЕ ДИСЦИПЛИНЫ .................................................................................................................................. 145 С.В. Ильичева АВТОМАТИЗИРОВАННАЯ СИСТЕМА РАЗРАБОТКИ САЙТОВ КАК RICH INTERNET APPLICATIONS НА БАЗЕ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ................................................................................ 149 А.Ю. Савельев, И.М. Радченко, В.Е. Подольский, В.Е. Красильников

Секция 3. Суперкомпьютинг РАЗРАБОТКА РАСПРЕДЕЛЕННОЙ СИСТЕМЫ ДИНАМИЧЕСКОГО ПРОГРАММИРОВАНИЯ НЕЛИНЕЙНЫХ ПРОЦЕССОВ С ПРИМЕНЕНИЕМ МНОГОШАГОВОЙ ОПТИМИЗАЦИИ ........................... 153 О.Н. Медведева, К.О. Боченина, А.А. Павлов, Т.В. Таравкова

7

ПАРАЛЛЕЛЬНЫЙ КОД ДЛЯ МОДЕЛИРОВАНИЯ ДИНАМИКИ СВЕРХЗВУКОВОГО ГАЗА С САМОГРАВИТАЦИЕЙ ....................................................................................................................................... 159 C.А. Хоперсков, М.А. Еремин, А.В. Хоперсков АРХИТЕКТУРА СИСТЕМЫ АВТОМАТИЗИРОВАННОГО АНАЛИЗА UPC-ПРОГРАММ............................. 164 Н.Е. Андреев РАСПРЕДЕЛЕННАЯ СИСТЕМА АВТОМАТИЧЕСКОГО ОБНАРУЖЕНИЯ СЕМАНТИЧЕСКИХ ОШИБОК В MPI-ПРОГРАММАХ............................................................................................................................................ 167 К.Е. Афанасьев, А.Ю. Власенко ОПТИМИЗАЦИЯ ПРОГРАММЫ МОДЕЛИРОВАНИЯ РАСПРОСТРАНЕНИЯ ВОЛНЫ ЦУНАМИ............... 173 А.Ф. Зайков ИСПОЛЬЗОВАНИЕ СИМУЛЯТОРА ВЫЧИСЛИТЕЛЬНОГО КЛАСТЕРА ДЛЯ ИССЛЕДОВАНИЯ АЛГОРИТМОВ ПЛАНИРОВАНИЯ ЗАДАЧ ...................................................................................................... 176 П.Н. Полежаев, В.П. Гергель СИСТЕМА МОНИТОРИНГА И УПРАВЛЕНИЯ КЛАСТЕРНЫМИ УСТАНОВКАМИ СЕМЕЙСТВА СКИФ – SkifMon ............................................................................................................................................................... 183 М.В. Гумин, М.В. Стоцкий ВЕРИФИКАЦИЯ АЛГОРИТМА ПОДДЕРЖКИ ТРАНЗАКЦИОННОЙ ПАМЯТИ ............................................ 186 А.Б. Беляев РАЗРАБОТКА ПРОГРАММНОГО КОДА ДЛЯ РЕШЕНИЯ ТРЕХМЕРНЫХ НЕСТАЦИОНАРНЫХ ЗАДАЧ ДИНАМИКИ ВЯЗКОЙ ЖИДКОСТИ В ПОЛЯХ ОБЪЕМНЫХ СИЛ. СОПОСТАВИТЕЛЬНАЯ ОЦЕНКА ЭФФЕКТИВНОСТИ ПАРАЛЛЕЛИЗАЦИИ ДВУХ ИТЕРАЦИОННЫХ МЕТОДОВ ......................................... 192 Б.Н. Цветков ОБРАБОТКА ВИДЕОИНФОРМАЦИИ С ИСПОЛЬЗОВАНИЕМ GRID-ВЫЧИСЛЕНИЙ ............................... 197 О.Н. Долинина, А.В. Ермаков

Материалы школы-семинара по технологиям распределенных вычислений и компьютерного моделирования ОБРАТНЫЕ ЗАДАЧИ ДИНАМИКИ КОРАБЛЯ ДЛЯ ВИЗУАЛИЗАЦИИ ЭКСТРЕМАЛЬНЫХ СИТУАЦИЙ В БОРТОВЫХ СИСТЕМАХ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ СУДОВОДИТЕЛЯ................................... 204 А.А. Безгодов, С.В. Иванов, А.В. Бухановский СЕРВИСНО-ОРИЕНТИРОВАННАЯ РАСПРЕДЕЛЕННАЯ СРЕДА УПРАВЛЕНИЯ ПРИКЛАДНЫМИ ВЫЧИСЛИТЕЛЬНЫМИ ПАКЕТАМИ................................................................................................................ 205 С.В. Марьин, С.В. Ковальчук ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ДЛЯ УПРАВЛЕНИЯ СЛОЖНЫМИ ТЕХНИЧЕСКИМИ ОБЪЕКТАМИ206 С.В. Иванов, Ю.И. Нечаев, А.В. Бухановский ОНТОЛОГИЧЕСКИЙ ПОДХОД К ПОСТРОЕНИЮ ИНТЕЛЛЕКТУАЛЬНОГО УПРАВЛЯЮЩЕГО ЯДРА СУПЕРКОМПЬЮТЕРНЫХ ПРИЛОЖЕНИЙ НОВОГО ПОКОЛЕНИЯ ............................................................. 208 С.В. Ковальчук, А.В. Бухановский ПРОФЕССИОНАЛЬНАЯ КОЛЛАБОРАТИВНАЯ ИНТЕРНЕТ-СРЕДА В ОБЛАСТИ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ В НАНОТЕХНОЛОГИЯХ................................................................................................. 210 А.А. Гуськов, А.В. Ларченко, С.В. Ковальчук МЕТОДОЛОГИЧЕСКИЕ АСПЕКТЫ РЕАЛИЗАЦИИ ПОВЕДЕНИЯ НЕСТАЦИОНАРНОЙ ДИНАМИЧЕСКОЙ СИСТЕМЫ В РАМКАХ ТЕОРИИ КАТАСТРОФ ............................................................................................... 211 Ю.И. Нечаев, О.Н. Петров КОНТРОЛЬ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИТУАЦИЙ С ИСПОЛЬЗОВАНИЕМ ИНТЕГРИРОВАННОЙ НЕЙРОННОЙ СЕТИ ........................................................................................................................................... 212 Ю.И. Нечаев, И.А. Власов

Индекс фамилий всех авторов статей ......................................................................................................... 214

8

Труды конференции Телематика’2010

Секция 1. Технологии и инфраструктура телекоммуникаций

СИСТЕМА МОНИТОРИНГА КОРПОРАТИВНОЙ СЕТИ НОВГОРОДСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА М.П. Журавлёва Новгородский государственный университет имени Ярослава Мудрого, г. Великий Новгород E-mail: [email protected] Цель разработки Целью данного проекта является разработка системы мониторинга корпоративной сети НовГУ, автоматизирующей сбор статистики и проверки различных параметров состояния серверов и сетевого оборудования (доступность сервисов, загрузка процессоров, интерфейсов, памяти, дисков и т.д.) и оповещающей администратора о возникающих проблемах. Актуальность При интенсивном развитии сети становится трудно отследить возможные отклонения в работе серверного и телекоммуникационного оборудования. Необходимо непрерывно следить за различными параметрами состояния серверов, сетевого оборудования, достижимостью подсетей и в случае обнаружения сбоев сообщать о них сетевому администратору. Эти задачи являются подмножеством задач управления сетью. Система мониторинга позволит автоматизировать проверки оборудования и сбор статистики о функционировании сети; в случае критических состояний сетевых служб, параметров серверов и оборудования, сетевой администратор может быть предупрежден по электронной почте или СМС. Это значительно снизит временные затраты на устранение критических состояний и повысит эффективность управления сетью. Новизна разработки На рынке имеются готовые аналоги систем мониторинга (платные и open-source). Среди open-source систем была проведена опытная эксплуатация систем мониторинга Nagios и Cacti, представляющих собой универсальные средства для мониторинга сетей. В результате было выявлено, что ни одна из этих систем не может в полной мере удовлетворить требованиям, т.к., например, с одной стороны, в Cacti отсутствует возможность проверки сетевых служб (http, ftp и др.). Nagios, в свою очередь, без дополнительных плагинов не может представлять информацию в графическом виде для отслеживания тенденций изменения параметров во времени. К тому же, обе системы достаточно сложны в эксплуатации, т.к. не могут предоставить полную картину о состоянии всех устройств сети. Разрабатываемая система будет закрывать потребности проверок в особо критичных случаях, одновременно предоставляя удобный пользовательский интерфейс, и интегрируя положительные возможности систем Nagios и Cacti (представление информации в графическом виде, проверка сетевых служб). Функциональные характеристики • Проверка сетевых служб: http, dns, ftp, imap, pop, smtp, dhcp, mysql. • Проверка дисков, свопа для серверов, проверка трафика на логических и физических интерфейсах, возможного возникновения broadcast-шторма, памяти, загрузки процессора для сетевых устройств. • Проверка достижимости подсетей, серверов и сетевого оборудования. • Уведомление о возникающих проблемах и восстановлении из критического состояния по электронной почте. • Представление данных по результатам проверок в графическом формате (использование RRDtool) и в текстовых лог-файлах (для сохранения более точных числовых данных). • Автоматическое архивирование текстовых лог-файлов за прошедший месяц в .tar.gz. архивы. • Возможность просмотра собранной статистики при условии, что устройство временно отключено. • Информация о серверах, сетевых устройствах, подсетях записывается в конфигурационный XMLфайл, который формируется за пределами Программы. Добавление/удаление устройств осуществляется путем редактирования конфигурационного файла. 9

• Для удобства использования в системе должна быть страница, показывающая критические состояния проверяемых параметров и служб, а также общая сводная страница, отображающая информацию о всех устройствах. Условия реализации • Система разрабатывается под операционной системой Linux Ubuntu 9.04, однако может функционировать на любом дистрибутиве Linux, FreeBSD и прочих UNIX-подобных системах. • Программный модуль разрабатывается на языке PHP (с поддержкой xml, snmp). • При разработки программы будут использованы следующие дополнительные средства: вебсервер Apache 2, RRDtool 1.3.1, SNMP, плагины Nagios 3.2.0 (check_dhcp, check_ftp, check_imap, check_smtp, check_udp , check_dns, check_http, check_pop, check_tcp ). Выбор наилучшего метода решения поставленной задачи В соответствии с требованиями к функциональности логически система делится на две части: собственно модули проверок и сбора статистики и модули представления результатов пользователю. Со стороны серверной части необходимо: • Определить, какие проверки для какого устройства/подсети осуществлять (парсинг конфигурационного XML-файла); • в соответствии с типом проверки (достижимость, доступность сетевых служб, анализ состояния дисков/памяти/интерфейсов и т.д.) собрать данные с помощью ping, ответа службы по требуемому порту, snmp-запроса соответственно; • поместить полученные данные в лог-файлы и кольцевую базу данных rrd; • проверить, изменилось ли состояние устройства, и в случае изменения состояния отправить оповещение сетевому администратору (таким образом, оповещение будет отправлено в случае, если на сервере или телекоммуникационном оборудовании было зафиксировано отклонение параметров от требуемых для стабильного функционирования, и в случае возвращения устройства к нормальной работе). Со стороны клиента – вывести запрашиваемые пользователем данные (построить графики, вывести сводную страницу о состоянии сети, предоставить возможность просмотра текстовых лог-файлов). Остановимся подробнее на каждой из задач в отдельности. Конфигурационный файл должен содержать следующую информацию: названия устройств, ipадреса, community, тип устройств, списки необходимых проверок, включаемых в мониторинг, также в нем содержатся указания каталога, где будут храниться лог-файлы и файлы rrd, каталога, куда будет установлена система мониторинга, пути к модулю php для осуществления запуска системы. Для парсинга конфигурационного XML-файла наиболее эффективным является применение расширения языка PHP для работы с XML DOM/XML, предоставляющего функции обращения к данным, содержащимся в XML-документе в соответствии с его структурой. Для осуществления проверок достижимости единственным методом является выполнение команды ping: ping -c 'N' 'ip_address', где 'N' – количество отправляемых ICMP-пакетов, 'ip_address' – ip-адрес устройства. Для сбора статистики и анализа состояния дисков/памяти/процессоров/интерфейсов – выполнение запроса по протоколу SNMP: snmpwalk -v2c -c 'community' 'ip_address' 'oid', где 'community' – имя сообщества (для обращения к устройству по протоколу SNMP), 'ip_address' – ipадрес устройства, 'oid' – Object Identifier – идентификатор объекта переменной, которая может быть прочитана или установлена через SNMP). Графическим представлением собранной статистики будут являться различные графики (описание способа их построения приводится ниже). Так, например, при проверке процессоров графики загрузки в течение дня/недели/месяца/года будут представляться следующим образом (рис. 1): Для проверки ответа сетевых служб в процессе разработки системы (разработка производилась под операционной системой Linux Ubuntu 9.04) изначально были применены плагины Nagios. Однако при переносе системы на операционную систему FreeBSD 7.3 было выявлено, что использование такого способа проверки служб не удовлетворяет требованию переносимости системы в различные операционные системы, поскольку требуют дополнительной настройки (необходимо загрузить исходные модули плагинов для используемой операционной системы и скомпилировать их в исполняемые приложения). Таким образом, необходимо использовать метод проверки доступности службы путем открытия socket'а по well-known порту, соответствующему анализируемой службе. PHP предоставляет функцию fsockopen для осуществления данного метода. Например: $fp=fsockopen("$server",$port,$errno,$errstr,$timeout); или (если требуется подключение по UDP (для проверки DHCP)): $fp=fsockopen("udp://".$server,$port,$errno,$errstr,$timeout);. 10

Труды конференции Телематика’2010

Рис. 1. Графики загрузки процессора В дальнейшем предполагается усовершенствовать данный метод проверкой правильности ответа службы путем осуществления запросов/ответов, соответствующих данной службе. В качестве возможных средств для отображения полученных данных в графическом формате можно рассматривать RRDtool и MRTG. MRTG (Multi Router Traffic Grapher) – является свободным программным обеспечением. Это инструмент для организации сервиса для мониторинга и измерения сетевого трафика с течением времени. Данные с различных сетевых устройств собираются при помощи протокола SNMP, а затем отображаются в виде графиков. Утилита первоначально была разработана для мониторинга трафика, но впоследствии превратилась в удобный инструмент для создания графиков и сбора статистических данных для различных задач и процессов. Областями применения MRTG на сегодняшний день являются: • загруженность канала (входящий, исходящий, максимальный, средний трафик); • использование процессора, оперативной памяти, жесткого диска; • наблюдение за температурными показателями аппаратных ресурсов; • погодные данные и т.д. RRDtool (Round-robin database tool) – набор утилит для работы с RRD. Предназначен для хранения и обработки динамических (изменяющихся во времени) последовательностей данных, таких как сетевой трафик, пропускная способность сети, загрузка ЦПУ и др. Все данные хранятся в кольцевой базе, размер которой остаётся неизменным. RRDtool, помимо прочего, включает в себя возможность графического отображения хранимой информации. Для системы мониторинга сети НовГУ в качестве утилиты для построения графиков был выбран RRDtool, т.к. способ хранения результатов в кольцевой базе данных значительно сократит использование диска сервера с установленной системой мониторинга, а также исключит необходимость следить за переполнением диска, поскольку размер базы данных будет оставаться постоянным. MRTG может самостоятельно использоваться как средство мониторинга сети, но его функциональность ограниченна, а использование как дополнительного средства более трудоемко, чем использование RRDtool. Помимо удобства хранения данных RRDtool был выбран в качестве средства для хранения информации и построения графиков также в силу гибкости описаний хранимых и отображаемых данных. С точки зрения реализации взаимодействия системы с RRDtool в процессе проектирования предполагалось использовать дополнительное расширение языка PHP с функциями для работы с RRDtool. Однако в операционной системе FreeBSD была выявлена проблема совместимости PHP с расширением RRDtool и веб-сервера Apache. Поэтому работа с кольцевой базой данных осуществляется при помощи стандартных функций исполнения программ exec или system, вызывающих команды RRDtool для создания, обновления rrd-файлов, а также построения графиков. RRDtool применяется для создания (rrdtool create) файлов .rrd кольцевой базы данных, их обновления (rrdtool update), построения графиков (rrdtool graph) по имеющимся файлам .rrd. Для создания/обновления .rrd файлов, построения графиков необходимо соответсвие структуры .rrd файла и параметров, передаваемых для его обновления или построения графиков. Обязательными элементами структуры .rrd файла являются: • "--step","'time_value'" – интервал агрегирования (в секундах); • "--start",0, – признак начального времени; 11

• "DS:'data_name':'DATA_TYPE':'heartbeat':'min':'max'", – описание данных (DS – data source, 'data_name' – имя источника данных, 'DATA_TYPE' – тип данных, 'heartbeat' в секундах, 'min', 'max' – при создании rrd равен U – unknown); • "RRA:'CONSOLIDATION_FUNCTION':'xff':'steps':'rows'" – описание для хранения данных в архиве round-robin archive (CONSOLIDATION_FUNCTION – функция объединения (тип хранения результата), xff – определяет размер интервала объединения при переходе из неизвестного состояния к определенному, задается отношением неизвестных данных к количеству данных за интервал (принимает значения от 0 до 1), steps – определяют, сколько базовых точек требуется для построения объединенной точки, помещаемой в архив rra, rows – определяют, сколько сгенерированных значений хранится в rra-архиве (должно быть больше 0)). Возможные типы данных DATA_TYPE: • GAUGE – применяется для таких данных, как температура, процент использования диска и т.д.; • COUNTER – счетчик – применяется для постоянно увеличивающихся счетчиков, таких как, например, число исходящих unicast-пакетов (ifOutUnicast) на каком-либо интерфейсе маршрутизатора. Предполагается, что счетчик никогда не уменьшается кроме случая переполнения (32- или 64-битной границы), переполнение обрабатывается RRDtool, возвращая правильный результат; • DERIVE – производная – применяется для хранения производной линии с началом в последнем полученном значении и ведущей к текущему значению. Принцип работы аналогичен счетчику COUNTER, однако без проверок переполнения 31- или 64-битной границы; • ABSOLUTE – абсолютное значение – применяется для счетчиков с тенденцией к переполнению или данных, отражающих некоторое количество объектов с момента предыдущего обновления; • COMPUTE – вычислимое поле – применяется для хранения вычислений с использованием других определенных в RRD источников данных. Возможные типы функции объединения CONSOLIDATION_FUNCTION: • AVERAGE – средние значения; • MIN – минимальное значение; • MAX – максимальное значение; • LAST – последние полученные данные. С использованием этих возможностей RRDtool доступно описание шаблонов для создания графиков с представлением данных, необходимых для анализа состояния какого-либо элемента устройства (например, рис. 2 использования корневого раздела диска).

Рис. 2. Графики использования диска В дополнение к хранению результатов в кольцевой базе данных результаты также будут храниться в текстовых лог-файлах для уточнения используемой в качестве первичной графической информации. Текстовые файлы будут содержать: время произведенных проверок и их результаты. Накопившиеся в течение месяца текстовые данные будут автоматически собраны в архив .tar.gz. Для реализации пользовательского интерфейса на клиенте больше всего подходит создание вебинтерфейса для удобного доступа (с предварительной авторизацией) к результатам выполняемых проверок. В качестве основной страницы представляются данные о критичных состояниях, 12

Труды конференции Телематика’2010

обнаруженных в сети на момент последней проверки, далее с использованием навигации методом гиперссылок пользователь может просмотреть состояние любого устройства/подсети в отдельности, либо вывести общую сводную страницу по всем указанным в конфигурационном файле серверам, подсетям и телекоммуникационному оборудованию. Литература 1. Cacti: The Complete RRDTool-based Graphing Solution: документация по Cacti [Электронный ресурс]. – Режим доступа: http://www.cacti.net/index.php, свободный. – Загл. с экрана. 2. Nagios – The Industry Standard in IT Infrastructure Monitoring: документация по Nagios [Электронный ресурс]. – Режим доступа: http://www.nagios.org/, свободный. – Загл. с экрана. 3. RRDtool – About RRDtool – документация по RRDtool [Электронный ресурс]. – Режим доступа: http://oss.oetiker.ch/rrdtool/index.en.html, свободный. – Загл. с экрана.

РАСШИРЕНИЕ ОБЛАСТИ ПРИМЕНЕНИЯ МОБИЛЬНЫХ РАДИОКОМПЛЕКСОВ С ПОМОЩЬЮ УПРАВЛЯЕМЫХ ТИПОВ МОДУЛЯЦИИ Ю.А. Дергачев ОАО «Концерн «Созвездие», г. Воронеж E-mail: [email protected] На данный момент разработка управляемых типов модуляции, программируемых модуляторов и демодуляторов, новых классов помехоустойчивых кодов и протоколов является важной технической задачей. Наметившиеся за последние годы тенденции к миниатюризации и увеличению пропускной способности каналов позволяют сделать вывод, что вычислительные сети, средства связи, системы оповещения и сигнализации в скором времени будут построены с помощью децентрализованных топологий, что значительно повысит их доступность для абонентов и живучесть при выходе из строя нескольких ретрансляционных узлов. При этом будет наблюдаться существенный рост роли мобильных абонентских устройств, которые кроме обычных пользовательских терминалов возьмут на себя роль промежуточных узлов маршрутизации, шлюзов, мостов и т.д. Таким образом, необходима разработка таких передатчиков и приемников, которые используют разные типы модуляции, обладают высокой помехоустойчивостью и имеют малые габариты, что позволяет использовать их в качестве мобильных терминалов. Данная задача решается с помощью создания SDR-систем – средств радиосвязи, в которой программное обеспечение используется как для модуляции, так и для демодуляции радиосигналов. Для этих целей разработана и запатентована универсальная аппаратная платформа синтезатора сигналов, на основе которой могут быть реализованы как уже известные, так и новые разработанные типы модуляции. Устройство является композитным и состоит из двух модулей: синтезатора прямоугольных импульсов с задаваемыми значениями по длительности и амплитуде каждого из них и конвертора передаваемых данных в канальные символы с учетом имеющегося алфавита и числа амплитудных градаций. Данное устройство имеет шину данных, для получения набора бит из буфера приема/передачи и шину управления, для задания модели каждого передаваемого символа. Синхронизация двух подсистем осуществляется с помощью общего генератора тактовых импульсов. Таким образом, большинство из существующих типов модуляции не требуют реализации в виде отдельного устройства, а могут быть представлены как программный код или сценарий управления программируемым синтезатором (Заявка на патент 2008132553/09 от 06.08.2008, постановление о выдачи патента от 12.10.2009, опубликован 20.02.2010). Разработаны совместимые с TCP/IP протоколы, поддерживающие сенсорные сети и дающие возможность применять методы динамической маршрутизации с моделями устранения парадоксов «туннелей», «каньонов» и других особенностей, которые приводят к неравномерному распределению нагрузки между маршрутами (что может повлечь за собой разрушение сети). При расширении области применения мобильных радиокомплексов особую роль играют алгоритмы автоматической настройки на состояние канала, механизмы выделения сигнала из помех и т.д. Многие задачи решаются только с помощью применения самообучающихся систем. Используя дополнительные разработанные устройства, методы и алгоритмы, может быть получен новый тип мобильного универсального радиокомплекса, распределенных вычислительных сетей как военного так и общего назначения. Программа выполняется при финансовой поддержке РФФИ (проекты 08-02-13555-офи-ц, 09-07-97522-р-центр-а). По теме работы опубликованы статьи и доложены результаты на конференциях: 1.

2.

Способ увеличения пропускной способности канала с малым уровнем шума Нечаев Ю.Б., Дергачёв Ю.А., Панкова М.А. // «Вестник Воронежского института МВД России», Воронеж 2008 г. Вып. 4. С. 81-86. Сигнально-кодовые конструкции без нулевой составляющей спектра // «Теория и техника радиосвязи» Ю.Б. Нечаев, Ю.А. Дергачев. Воронеж, 2009. Вып. 3, С. 30-34. 13

3.

Применение нейронных сетей в задачах управления маршрутизацией Нечаев Ю.Б., Дергачев Ю.А. // «Вестник Воронежского государственного университета». Серия: Системный анализ и информационные технологии. 2009. № 1. С. 42-45. 4. Нелинейное статическое уравнивание канала с QAM модуляцией Ю.Б. Нечаев, Ю.А. Дергачев // «Вестник Воронежского государственного технического университета», Воронеж 2010 г. Том 6. Вып. 2. С. 48 -50. 5. Энергоэффективность кооперативной маршрутизации в беспроводных сетях Ю.Б. Нечаев, Ю.А. Дергачев // «Теория и техника радиосвязи», Воронеж 2010 г. Вып. 1. С. 52-56. 6. Разработка программного комплекса для расширения возможностей аналоговых радиостанций/ Ю.Б. Нечаев, Ю.А. Дергачев // Материалы Восьмой Международной научнометодической конференции «Информатика: проблемы, методология, технологии», Воронеж, 2008 г. – Воронеж: ВГУ, 2008. – Т.2. – С. 120-124. 7. Новая методология построения многоцелевых радиокомплексов/ Ю.Б. Нечаев, Ю.А. Дергачев, М.А. Панкова // Материалы VII Международной научно-технической конференции «Физика и технические приложения волновых процессов», Самара, 2008 г. – Самара: «Самарское книжное издательство», 2008. – С. 83-84. 8. Модификация метода макетного сжатия аудиоданных и протокола передачи оцифрованной речи с журналом доставленных пакетов для систем с малой пропускной способностью каналов связи/ Ю.Б. Нечаев, Ю.А. Дергачев // Материалы Девятой Международной научнотехнической конференции "Проблемы техники и технологии телекоммуникаций", Казань, 2008 г. – Казань: Изд-во Казан. гос. техн. ун-та, 2008. – C. 187-188. 9. Модифицированный алгоритм селектора сигнально-кодовых конструкций/ Ю.Б. Нечаев, Ю.А. Дергачев //Сборник трудов первой Международной научно-технической конференции «Компьютерные науки и технологии», Белгород, 2009 г.– Белгород: ГиК, 2009. – Ч.2.– С. 6973. 10. Генерирование случайных многопараметрических сигналов/ Ю.Б. Нечаев, Ю.А. Дергачев // Материалы VIII Международной научно-технической конф. «Физика и технические приложения волновых процессов», Санкт-Петербург, 2009 г.– СПб: Политехника, 2009. – С. 63–65. 11. Нечаев Ю.Б Генерирование случайных многопараметрических сигналов/ Ю.Б. Нечаев, Ю.А. Дергачев // Материалы VIII Международной научно-технической конф. «Физика и технические приложения волновых процессов», Санкт-Петербург, 2009 г.– СПб: Политехника, 2009. – С. 63-65. Разработано программное обеспечение: 1.

2.

3.

4.

Нечаев Ю.Б., Дергачев Ю.А., Латышева Е.В. Свидетельство о государственной регистрации программы для ЭВМ № 2008614674. «Снайпер 1». Зарегистрировано в Реестре программ для ЭВМ 29 сентября 2008 г. Нечаев Ю.Б., Дергачев Ю.А., Латышева Е.В. Свидетельство о государственной регистрации программы для ЭВМ № 2008613246. «Решатель 1.0». Зарегистрировано в Реестре программ для ЭВМ 7 июля 2008 г. Нечаев Ю.Б., Дергачев Ю.А., Латышева Е.В. Свидетельство о государственной регистрации программы для ЭВМ № 2009611208. «Инней». Зарегистрировано в Реестре программ для ЭВМ 15 мая 2009 г. Нечаев Ю.Б., Дергачев Ю.А. Свидетельство о государственной регистрации программы для ЭВМ № 2008610500 «Юдифь» Зарегистрировано в Реестре программ для ЭВМ 30 апреля 2008. г.

Получен патент: 1.

14

Заявка 2008132553 Российская Федерация, МПК H 04 K 1/02. Устройство построения распределенных систем передачи данных и способ его реализации/ Дергачев Ю.А.(РФ), Нечаев Ю.Б.(РФ); заявитель ГОУ ВПО ВГУ/ Заявл. 6.08.08. постановление о выдачи патента от 12.10.2009, опубликован 20.02.2010.

Труды конференции Телематика’2010

РАСШИРЕНИЕ МОДЕЛИ МНОГОПРОДУКТОВОЙ СЕТИ ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ СЕТИ ИНТЕРНЕТ-ПРОВАЙДЕРА М.А. Хенкин Московский государственный институт радиотехники, электроники и автоматики (технический университет) E-mail: [email protected] Введение Постоянно растущая конкуренция на рынке услуг предоставления доступа в Интернет вынуждает провайдеров снижать цены на услуги, что в свою очередь приводит к росту абонентского трафика без повышения доходов. Для увеличения прибыли Интернет-провайдеры вводят новые услуги, качественное предоставление которых определяется готовностью сети к новым классам трафика. В данных условиях основным требованием для сохранения абонентской базы является эффективное использование ресурсов сети, а также своевременная и адресная модернизация. Вышесказанное обуславливает необходимость математического моделирования провайдерских сетей с целью оптимизации алгоритмов маршрутизации. Для повышения эффективности сетей Интернет-провайдеров актуально рассмотрение процессов приоритезации и инкапсуляции абонентского трафика, а также ограничений, возникающих в сети вследствие применения методов коммутации пакетов. В работе рассматривается расширение типовой модели абонентской сети, и предлагаются модифицированные методы повышения эффективности сетей на базе расширенной модели с целью их применения в реальных сетях Интернетпровайдеров. Типовая модель сети Функционирование абонентской сети формализуется типовой математической моделью, которая называется многопродуктовой потоковой сетью (МП-сетью) и задается с помощью двух графов на пересекающемся множестве вершин [1–7]. Первый граф отражает физическую топологию сети, множество вершин которого

V = {v1 ,...,vn } делится на два класса:

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

ek ∈ E , k ∈ R = {1,..., r} первого (физического) графа соответствуют каналам связи них заданы веса: y k – пропускная способность ребра, c k – стоимость пропуска единицы

Ребра сети, на

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

pi = (vs(i) ,vt(i) ),i ∈ M = {1,2,...,m}

соединяют те пары вершин, которые обмениваются друг с

другом данными, то есть образуют тяготеющие пары. Каждая тяготеющая пара на поток

pi

создает требования

d i – величина потока, необходимого тяготеющей паре.

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

z =( z1 ,..., z m ) . Мультипоток может быть реализован на физическом графе различными распределениями потоков по его ребрам. Распределение

тяготеющими парами, задается вектором мультипотока определяется матрицей

{ f ik } .

Каждый элемент матрицы

f ik

обозначает поток

i−й

тяготеющей

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

∑ f ik ≤ yk ∀k ∈ R .

i∈M

Постановка задачи оптимизации Процесс оптимизации сети провайдера состоит в определении оптимального алгоритма маршрутизации (дизайна сети), который обеспечивает максимальную пропускную способность сети и удовлетворяет всем поставленным граничные условия. При выборе наилучшего дизайна сети из множества возможных, используются следующие два критерия для оценки качества и оптимальности дизайна [8]: 15

• Для всех требований тяготеющих пар максимальная нагрузка на ребро должна быть, по возможности, минимальной. • Для всех требований тяготеющих пар маршруты, по возможности, должны быть минимальной стоимости (далее будем называть такие маршруты кратчайшими). Конкретная мера стоимости может изменяться для разных сетей в зависимости от административных ограничений. Если единственной мерой является длина пути, то все веса полагаются равными. Наиболее распространенные меры качества звеньев [1, 8]: • величина, обратная коэффициенту надежности линии; • задержка на канале; • расстояние; • интегральная характеристика, учитывающая несколько показателей качества; • денежная стоимость пропуска трафика (мера характеризует не качество линии, а затраты по ее строительству или эксплуатации). Вследствие того, что оптимизация сети только на основе первого критерия может привести к формированию неэффективного маршрута, был введен второй критерий. Использование второго критерия позволяет выбрать только те маршруты, которые, по возможности, являются кратчайшими при соблюдении первого критерия. Для повышения эффективности сетей Интернет-провайдеров актуально рассмотрение следующих оптимизационных задач. Задача 1. Для заданного вектора требований увеличения потока

λmax

d =(d1 ,..., d m )

такой, что сеть с вектором требований

найти максимальный коэффициент

λmax d

является допустимой.

Задача 2. Для заданного вектора требований найти допустимое распределение потоков минимальной стоимости в МП-сети. Задача 3. Для заданного вектора требований выбрать среди конечного множества сетей (топологий физического графа) такую сеть, для которой коэффициент

λmax будет максимальным.

Задача 4. Для заданного вектора требований выбрать среди конечного множества сетей такую сеть, для которой суммарная стоимость пропуска потока будет минимальной.

λmax < 1 , что поиска λmax может

Отметим, что решением задачи 1 может оказаться значение недопустимой МП-сети. Также следует отметить, что задача

соответствует пониматься в

def

векторном смысле:

λmax = (λ1max ,..., λmmax ) , тогда λmax d = (λ1max d1 ,..., λmmax d m ) .

Задачи 3–4 являются задачами синтеза сетей. Конечное множество вариантов конфигурации сети определяется, исходя из административных ограничений, которые возникают при проектировании сетей в заданных условиях. Существует ряд работ, посвященных методам решения приведенных задач оптимизации МП-сетей [2–8]. Рассмотрение конкретных методов выходит за рамки данной работы. Далее мы будем рассматривать методы только в контексте дополнительных ограничений и изменений, которые возникают вследствие расширения типовой модели МП-сети. Расширение типовой модели Типовая модель МП-сети является абстрактной моделью сложной сетевой системы, которая отражает лишь общие сетевые свойства, такие как наличие входов/выходов, транспортных магистралей и резервных каналов, а также существование различных пользователей и сетевых сервисов. Типовая модель обладает рядом существенных ограничений, которые не позволяют эффективно решать перечисленные выше задачи оптимизации для сетей Интернет-провайдеров [1, 7, 8]: • Модель не учитывает механизмов инкапсуляции трафика, которые часто применяются в сетях Интернет-провайдеров. • Модель не учитывает особенностей сетей с коммутацией пакетов. • Модель не учитывает возможности приоритезации трафика, необходимость в которой естественным образом возникает в сетях провайдеров из-за разнообразия услуг (доступ в Интернет, IP-телефония, потоковое видео, и т.д.) и классов абонентов (например, физические и юридические лица). Рассмотрим перечисленные ограничения более детально и предложим преобразования типовой модели, которые позволят применять методы оптимизации МП-сетей в реальных сетях Интернетпровайдеров. Моделирование инкапсуляция трафика Важным ограничением типовой модели МП-сети для решения задач оптимизации сетей Интернетпровайдеров является невозможность учета механизмов инкапсуляции трафика. Механизмы инкапсуляции трафика применяются для организации виртуальных частных сетей (VPN – Virtual Private Network), например, для объединения в единую корпоративную сеть нескольких филиалов организации. 16

Труды конференции Телематика’2010

Кроме того, в сетях провайдеров широко распространен метод авторизации абонентов с использованием VPN [9]. При использовании данного метода поток от абонента до сервера авторизации доставляется по виртуальному туннелю, что приводит к появлению избыточного трафика, который возникает вследствие инкапсуляции абонентского трафика для организации туннеля. На сервере авторизации трафик распаковывается и далее по сети проходит до узла назначения без инкапсуляции. С целью повышения эффективности актуальным является рассмотрение вопроса расположения серверов авторизации в сети, а именно, определение их оптимальной удаленности от пользователей. С одной стороны, провайдеру удобно иметь централизованные сервера авторизации (удобство обслуживания, надежность, возможность резервирования). С другой стороны, при централизации увеличивается нагрузка на сеть за счет избыточного инкапсулированного трафика, проходящего от границ сети в центр и обратно. Таким образом, основываясь на потоковой эффективности, оптимальным является расположение серверов авторизации ближе к абонентам. Описанная проблема является иллюстрацией применения 3-й и 4-й задач. В типовой модели МП-сети должно выполняться условие сохранения потока во всех транзитных вершинах [1, 2, 7, 8]. В той транзитной вершине, где трафик инкапсулируется или деинкапсулируется (то есть на границе виртуального туннеля), сохранение потока нарушается. Для реализации возможности моделирования инкапсуляции трафика необходимо тяготеющую пару, поток которой инкапсулируется при прохождении по физической сети, разбить на пары, соответствующие потокам с инкапсуляцией и без. Свойства новых тяготеющих пар наследуются от исходных пар, при этом для пар, соответствующих инкапсулированному потоку, величина потока выражается линейной функцией от исходного потока

f e = encap( f ) .

Существенным является то, что в отличие от исходной модели, приведенное преобразование модели нарушает свойство сохранения потока в транзитных вершинах. Но, поскольку функция преобразования потока известна и линейна, то общность модели не нарушается [7]. Кроме того, полученные при преобразовании типовой модели новые тяготеющие пары, соответствующие общей исходной паре, не могут рассматриваться независимо друг от друга. Согласно вышесказанному, любое изменение потока какой-либо дополнительной тяготеющей пары требует пересчета потоков всех пар, относящихся к исходной паре. Моделирование сетей с коммутацией пакетов Для того чтобы учесть особенности сетей с коммутации пакетов, а именно, для возможности моделирования ограничений пропускной способности и задержки не только на ребрах, но и в транзитных вершинах, каждую транзитную вершину исходного физического графа (которой соответствует определенное коммуникационное устройство реальной сети) представим в виде ориентированного подграфа. Вершинами подграфа являются:

p1 ;...; pn , к которым присоединяются смежные ребра исходного графа; внутренние вершины in; out , соответствующие точками входа и выхода внутренней шины

• порты •

коммуникационного оборудования. Ребрами подграфа являются: • входные ребра, направленные от портов к внутренней вершине • центральное ребро

(p1 ,in);...;(pn ,in) ;

(in,out) , соответствующее внутренней шине (коммуникационной матрице)

оборудования; • выходные ребра, направленные от внутренней вершины к портам:

(out, p1 );...;(out, pn )

(рис. 1). Поток на ребрах подграфа вычисляется как линейная функция от исходного потока, проходящего s через узел исходной сети: f = packet f . Целью преобразования исходного потока является введение дополнительных ограничений на пропускную способность обработки пакетов, что соответствует свойствам сетей с коммутацией пакетов. На ребрах, направленных от портов (к портам) может быть задана производительность обработки входящих (исходящих) пакетов непосредственно на

( )

портах. На центральном ребре

(in,out)

задается пропускная способность центральной шины (или

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

17

Рис. 1. Преобразование узла исходной сети для учета особенностей сетей с коммутацией пакетов Следует отметить, что приведенное преобразование приводит к существенному увеличению

размерности модели: для каждой транзитной вершины добавляется n − 1 вершин и 2n + 1 ребер, где n – число портов устройства, которому соответствует исходная вершина физического графа. Однако в результате данного преобразования новых маршрутов в сети не образуется, то есть усложнения структуры модели не происходит, а появляются дополнительные необходимые ограничения. Моделирование приоритезации трафика Ограничением, характерным для типовой МП-сети, является равнозначность всех тяготеющих пар, что не позволяет применять методы приоритезации трафика QoS [8]. Задача приоритезации трафика в сети ставится в том случае, когда суммарный запрос на поток всех тяготеющих пар не является допустимым. В этом случае некоторые (или, в худшем случае все) потоки начинают конкурировать за ресурсы сети на перегруженных ребрах. В качестве приемлемого распределения потоков в работе [7] предлагается выбирать конкурентный 0 0 поток z и соответствующее ему конкурентное распределение потоков { f ij } – решение оптимизационной задачи:

max min

z∈X ( y ) i∈M где

zi di

,

(1)

X(y) – множество допустимых векторов мультипотока z .

Значение (1) назовем величиной максимальной обеспеченности требований тяготеющих пар МПсети и обозначим

θ

θ . Тогда разность θ − 1 количественно характеризует меру недопустимости сети, а

отношение 1 / показывает величину необходимого увеличения пропускной способности ребер для того, чтобы сеть стала допустимой. Конкурентное распределение потоков максимизирует уровень обеспеченности потоковых требований тяготеющих пар, тем самым реализуется идея справедливого распределения потоков. Недостаток данного решения с аналитической точки зрения заключается в том, что максимизируется суммарный поток без учета свойств конкретных тяготеющих пар, при этом всем тяготеющим парам обеспечивается только доля их требований, в то время как по структуре сети требования многих тяготеющих пар могли бы быть обеспечены полностью. В реальных сетях Интернет-провайдеров трафик, напротив, дифференцируется по классам обслуживания, который определяется свойствами услуги. Авторы работы [7] в качестве меры приоритезации потоков предлагают закладывать приоритеты в их потоковых требованиях при постановке задачи о конкурирующих потоках. Такой способ позволяет аналитически оценить возможности сети, но не указывает на оптимальную конфигурацию оборудования по настройке механизмов QoS. Таким образом, рассмотренная методика позволяет достаточно эффективно оценить производительность сети, но не указывает на дизайн сети, при котором достигается оптимальная производительность. Ниже предложен алгоритм, позволяющий учесть возможность приоритезации различных классов трафика (рис. 2).

18

Труды конференции Телематика’2010

Q1 ,..., Qs n =1

P=P∪n

Рис. 2. Блок-схема алгоритма приоритезации трафика в МП-сети 1.

В первую очередь потоки всех тяготеющих пар классифицируются и упорядочиваются по приоритету:

2.

3.

4.

Q1 ,..., Qs

.

Далее рекурсивно проверяется допустимость сети при увеличении потоков наиболее приоритетных тяготеющих пар. Если в модели учитывается мера качества (то есть решается задача 2), то распределение приоритетных потоков производится по алгоритму кратчайшего пути в графе (например, по алгоритму Дейкстры). Когда сеть становится недопустимой, для определения полного вектора мультипотока решается задача в постановке (1). Согласно вышесказанному, решение конкурентное распределение потоков является уравнительным для всех тяготеющих пар. В свою очередь, это соответствует справедливой конкуренции потоков в сетях с коммутацией пакетов, при которой потоки перемешиваются в общей очереди коммуникационных устройств без приоритезации. В том случае, если полученное решение является приемлемым, то есть распределение потоков можно считать справедливым исходя из практических критериев реальной сети и полученных классов приоритетов, то задача считается решенной. Пары, попавшие во множество P , могут быть обеспечены методами приоритезации с наилучшим возможным качеством, остальные классы конкурируют между собой на равных условиях и их потоки распределяются в соответствии с (1). В противном случае необходимо перераспределить приоритеты потоков, либо сделать вывод о необходимости увеличения пропускной способности сети. Нехватка пропускной способности для недостаточно обеспеченных потоков характеризуется полученным из решения (1)

θ

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

• Построить (параметризовать) расширенную модель сети. • Свести методы оптимизации расширенной модели к уже исследованным методам оптимизации МП-сетей. • Отобразить полученные результаты на реальную сеть. Предложенная методика позволяет более точно формализовать и решать задачи повышения эффективности реальных сетей Интернет-провайдеров на основании описанных методов расширения модели МП-сети. Литература 1.

2. 3. 4. 5. 6.

7.

8.

9.

Громов Ю.Ю. Синтез и анализ живучести сетевых систем / Ю.Ю. Громов, В.О. Драчев, К.А. Набатов, О.Г. Иванова // Монография. – Москва: Машиностроение-1, 2007. – С. 3– 48. Assad А.А. Multicommodity network flows: А survey // Networks, 1978. – V. 8, N. 1. Kennington J.L. А survey of linear cost multicommodity network flows // Oper. Res., 1978. – V. 26, N. 2. Goldberg A. A New Approach to the Maximum-Flow Problem / A. Goldberg, R. Tarjan // Journal of the Association for Computing Machinery, 1988. – V. 35, N. 4, P. 921–940. Fleisher L. Approximating multicommodity flow independent of the number of commodities // Discrete Math., 2000. – N 13(4), P. 505–520. Castro J. An implementation of linear and nonlinear multicommodity network flows / J. Castro, N. Nabona // European Journal of Operational Research Theory and Methodology, 1996. – P. 37–53. Малашенко Ю.Е. Суперконкурентное распределение потоков в многопродуктовых сетях / Ю.Е. Малашенко, Н.М. Новикова // Дискретный анализ и исследование операций. – Новосибирск: ИМ СО РАН, 1997. – Серия 2, Т. 4, № 2, С. 34–54. Будылгина Н.В. Оптимизация сетей с многопротокольной коммутацией по меткам / Н.В. Будылдина, Д.С. Трибунский, В.П. Шувалов // Монография. – Горячая Линия – Телеком, 2010. Cisco Systems, Inc. VPDN Technology Overview // http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/vpdn_config/vpc1insb.pdf – 2006. – P. 23-29.

СИСТЕМА ОРГАНИЗАЦИИ ЭЛЕКТРОННЫХ ЛЕКЦИЙ С ВИДЕОКОНФЕРЕНЦСВЯЗЬЮ И РАЗНОРОДНЫМ ИНТЕРАКТИВНЫМ ДЕМОНСТРАЦИОННЫМ РЯДОМ В.В. Казаков, Г.Д. Безматерных Мультимедиа центр Новосибирского государственного университета, г. Новосибирск E-mail: [email protected] В последнее время часто бывает необходимо организовывать общение людей на расстоянии. Такой подход позволяет сэкономить денежные средства и время в таких случаях, как, например, ежедневные совещания руководителей компании и глав ее филиалов. Кроме того, общение на расстоянии незаменимо в случае, если собрать всех участников в нужном месте в нужное время не возможно, например, если нужна срочная консультация у специалиста. В образовательном процессе также часто приходится отказываться от живого общения, и зачастую было бы удобнее передать учебный материал дистанционно, чем собирать всех слушателей и лектора в одном месте. Это в основном относится к заочным формам обучения, в том числе к дистанционному образованию. Однако такой подход имеет место и в очном образовании, так как в вузе может не оказаться достаточно хорошего лектора по тому или иному предмету или специалиста в какой-либо узкой области. Видеосвязь обеспечивает лучшее восприятие информации по сравнению со всеми другими видами удаленных коммуникаций, даже если их использовать одновременно. Возможность в процессе разговора следить за жестикуляцией и мимикой собеседника резко повышает КПД передачи информации. Еще более эффективной видеосвязь получается при дополнении ее демонстрационными материалами [1]. Из всех способов организации видеосвязи самыми доступными и удобными являются видеоконференции на основе IP-сетей. В настоящее время создано множество таких систем, в том числе и свободно распространяемых, позволяющих решать общие задачи удаленного общения. Однако зачастую в связи со спецификой передаваемой информации общие решения становятся неприемлемыми. Для удаленной консультации врачом пациента нужны средства осмотра и передачи жизненных показателей, для удаленных деловых совещаний необходима возможность совместной работы над документами. 20

Труды конференции Телематика’2010

Уникальный подход нужен и для дистанционных лекций. Помимо видеосвязи, система чтения удаленных лекций должна обеспечивать возможность представлять демонстрационный ряд. Такая система должна: • Предоставлять различные типы демонстраций – тексты, научную графику, видеозаписи экспериментов, математические формулы, трехмерные модели и т.д. • Предоставлять инструменты управления демонстрациями в процессе чтения лекции, например, позиционирование видеозаписи эксперимента или вращение трехмерного графика. Кроме того, лектору необходима обратная связь с аудиторией: видео-общение со слушателем, задавшим вопрос, интерактивное тестирование, форум и т.п. В настоящее время не существует систем, ориентированных на организацию дистанционного проведения лекций, совмещающих видеоконференцсвязь и возможность сопровождения лекции демонстрацией учебных материалов различных типов и их интерактивным управлением. Цель настоящей работы заключается в исследовании и разработке способов создания средств проведения дистанционных лекций в виде видеоконференций, сопровождаемых сложным интерактивным демонстрационным рядом, с возможностью сохранения и дальнейшего использования. Практическая ценность работы состоит в создании мультимедиа-лектория – системы для ведения лекционного процесса, обладающей набором средств, существенно повышающих эффективность дистанционного чтения лекции. Такая система может быть использована в заочном образовании, лекциях ведущих специалистов узких областей науки для небольшого числа разбросанных по всему миру пользователей и других случаях В процессе работы был проведен анализ существующих систем видеоконференций (Microsoft Netmeeting [2], Microsoft Windows Messenger [3], Microsoft ConferenceXP [4], Skype [5]). Анализ показал, что стандартные системы видеоконференций не могут эффективно выполнять задачу удаленного образования в основном вследствие отсутствия средств эффективной организации и представления учебного демонстрационного материала. В результате проведенного анализа систем, которые могут быть использованы для дистанционного чтения лекций, был выявлен ряд требований к мультимедиа-лекторию. Во-первых, такая система должна предоставлять видеосвязь со стороны лектора. Согласно зарубежным исследованиям, при телефонном разговоре воспринимается только десятая часть транслируемой абонентом информации. Использование телефонной связи в совокупности с факсимильной позволяет увеличить объем эффективно усваиваемой информации примерно до 25%. В случае же, когда есть возможность в процессе разговора следить за жестикуляцией и мимикой собеседника, КПД передачи информации достигает 60%, что уже приближается к эффективности «живого» общения. Дело в том, что помимо речи люди при общении обладают мимикой, жестикуляцией, принимают позы, это происходит не осознанно. Мимика и жесты сосредотачивают собеседника, привлекают его внимание, акцентируют какие-либо детали разговора и передают другую дополнительную информацию [1]. Во-вторых, при чтении лекции лектору необходимо оперировать некоторым демонстрационным рядом. Демонстрационный ряд должен предоставлять широкий спектр типов демонстраций, не ограничивающий лектора в возможности сделать лекцию максимально интересной и эффективной. Демонстрации должны предоставлять различные динамические и интерактивные элементы, удовлетворяя желание лектора управлять демонстрациями во время чтения лекции. Для управления демонстрациями лектору предоставляются специальные инструменты. В-третьих, создание демонстрационного ряда должно осуществляться лектором, который может не иметь особых навыков работы с компьютером. Таким образом, для реализации системы удаленного чтения лекций необходимо разработать систему создания, редактирования и хранения демонстрационного ряда. Такая система должна обладать интуитивно понятным интерфейсом создания и редактирования демонстраций. В-четвертых, для повышения эффективности лекции необходимо реализовать различные пути обратной связи лектора с аудиторией. Лектору необходимо проверять знания слушателей при чтении лекции c помощью различных тестов, чтобы обратить внимание отдельных слушателей на проблемы в понимании материала или вовремя скорректировать курс лекции при плохом усвоении материала значительной части слушателей. Система тестирования должна быть развитой и предоставлять множество различных типов тестов. Слушателям необходима возможность в процессе и после лекции задавать вопрос лектору для уточнения каких-либо деталей материала. Также необходимы инструменты общения слушателей друг с другом во время лекции и после нее. В-пятых, большую ценность будет иметь запись лекции, которая позволит пользователям получать знания без участия лектора. Запись можно просматривать любое количество раз, приостанавливать для дополнительного размышления, перематывать на нужное место и т.д., что является факторами, повышающими удобство пользования материалом. Запись лекции желательно представлять в сети Интернет и в виде локальной копии. Локальная копия удобнее Интернет-версии для пользователей, не обладающих дешевым каналом с большой пропускной способностью, достаточной для передачи видео приемлемого качества. Лектор может распространять лекции на CD-ROM на коммерческой основе. На основе предъявленных требований к системе предлагается оригинальный подход к разработке мультимедиа-лектория. Основная трудоемкость и специфика разрабатываемой системы лежит в области создания, хранения и управления учебными материалами разных типов и их синхронизацией с видеосвязью. 21

Необходимо обеспечить независимость системы от конкретных протоколов и возможность замены протокола сетевой передачи данных, не перестраивая всю систему. Для этого нужно вынести всю логику передачи данных в отдельный модуль и спроектировать систему независимой от него. Эффективным решением будет использование LCMS-системы (Learning Content Management System – Система управления контентом образовательного назначения) со встроенными блоками видеосвязи, управления и передачи по сети команд управления демонстрациями. Для эффективной реализации мультимедиа-лектория используемая CMS-система должна обладать рядом свойств: • Необходим объектный подход к классам демонстраций – полиморфизм слайдов, реализация управления динамическими элементами, в методах класса. • Открытость системы в отношении разработки сложной модели данных, так как структура учебных материалов отличается некоторой сложностью. • Возможность интеграции системы с видеосвязью. Подробнее о системах управления контентом образовательного назначения можно прочитать в работах [6–8]. Управление объектами демонстраций предлагается осуществлять через систему команд, которые могут быть переданы, сохранены и воспроизведены повторно этим объектом. Клиентское приложение на стороне лектора управляет объектами демонстраций и когда лектор совершает какое-либо действие над ними, приложение формирует команду демонстрации, исполняет ее и отправляет копию команды клиентским приложениям слушателей. Клиент слушателя, получив команду, исполняет ее. Таким образом, все действия лектора над демонстрациями дублируются на стороне слушателя.

Рис. 1. Архитектура мультимедиа-лектория для режима онлайн лекции На основе предложенного подхода нами спроектирован мультимедиа-лекторий, в основе которого лежит следующая архитектура. Мультимедиа-лекторий состоит из серверной части, клиента лектора и клиента слушателя. Главная составляющая серверной части – сервер LCMS. Он предназначен для хранения демонстрационного ряда. Демонстрации создаются и редактируются лектором с помощью вебинтерфейса редактирования. Лектору предоставляются демонстрации разных типов, реализованные полиморфными классами. В серверной части также могут быть видеосерверы, используемые для передачи видео с компьютера лектора на множество компьютеров слушателей. Их назначение – рассылка видео всей аудитории с помощью группового вещания по интернет-сети. Клиент лектора, как и клиент слушателя, состоит из модуля управления, модуля коммуникаций и окна демонстраций. 22

Труды конференции Телематика’2010

В режиме онлайн лекции (рис. 1) лектор с помощью инструментов управления манипулирует демонстрациями, в результате чего клиент лектора получает информацию о манипуляциях для отправки клиенту слушателя. Клиент слушателя, получив информацию, разбирает ее и дублирует действия лектора. Модуль управления управляет модулем коммуникаций и окном демонстраций. Модуль управления получает из окна демонстрации команду на передачу вызова метода, преобразует ее в универсальный протокол, который передает модулю коммуникаций. Кроме того, модуль управления отвечает за инициализацию сеанса чтения и просмотра лекции, сохранение прочитанной лекции, организацию обратной связи и т.д. Модуль коммуникаций лекторского клиента отвечает за передачу видео и команд демонстраций модулю коммуникаций слушателя и видеосерверу, который рассылает входящее видео и команды управления демонстрациями всей аудитории. Заметим, что для обеспечения независимости системы от конкретных протоколов и возможности замены протокола сетевой передачи данных, не перестраивая всю систему, было решено вынести всю логику передачи данных в отдельный модуль коммуникаций и спроектировать систему независимой от него. Окно демонстраций отвечает за отображение и манипулирование демонстрациями. Модуль управления на клиенте лектора получает из окна демонстраций строку, содержащую команду управления демонстрацией. Эта команда содержит метод с параметрами, который необходимо выполнить на стороне слушателя, чтобы продублировать действие лектора. Мультимедиа-лекторий предоставляет лектору широкие возможности для разработки и представления демонстрационного ряда. Так, лектор может создавать текстовые слайды в html-формате с таблицами, изображениями и др. объектами. На таких слайдах лектор в процессе чтения лекции может выделять произвольные части текста, например, жирным шрифтом. Также лектор может рисовать маркером поверх текста или акцентировать внимание специальным указателем. Другой тип слайда – векторная графика предназначен для представления научной графики и позволяет лектору в процессе лекции масштабировать изображение, поворачивать и т.п. На этом типе слайда также можно рисовать маркером и пользоваться указкой. Пометки, нанесенные непосредственно на изображение привязываются к нему, и при масштабировании и позиционировании изменяются синхронно с основным изображением. Слайд с видеоизображением предназначен для демонстраций научных мини-фильмов – физических экспериментов, динамических моделей и т.п. Лектор может в процессе лекции приостанавливать видео, проигрывать по отдельным кадрам, масштабировать. Одним из критически важных условий дистанционного чтения лекции является наличие различных способов обратной связи. В мультимедиа-лектории представлен широкий ряд инструментов обратной связи – видеовопрос, тестирование, чат, форум и т.д. Видеовопрос представляет собой сеанс видеосвязи между лектором и одним слушателем, который видят все остальные слушатели. Видеовопрос является аналогом обычного вопроса слушателя лектору в очной форме проведения лекции и является неотъемлемой частью лекции. Слушатель отправляет запрос на видеосвязь лектору. Лектор, получив запрос, может принять его спустя некоторое время или сразу или отклонить его. Слушатель, задавший вопрос, получит уведомление о том, принял лектор его вопрос или отклонил. Тестирование представляет собой набор разных типов заданий аудитории и передача результатов лектору. Разные типы тестов представлены полиморфными классами. Лектор в реальном времени получает статистику ответов слушателей и может отправить ее аудитории. Тестирование может быть использовано лектором для корректировки курса, или чтобы обратить внимание слушателя на плохую успеваемость, может это использоваться и в других целях. Тестирование может проводиться в любой момент во время лекции. Лектор выбирает необходимый тест из демонстрационного ряда и отправляет слушателям, слушатели получают вопрос и варианты ответа, выбирают правильный ответ, и подтверждают выбор нажатием кнопки «ОК». После этого лектор получает детальную статистику ответов на вопрос, и если сочтет нужным, отправит отчет в аудиторию. Чат в основном предназначен для общения аудитории между собой во время лекции. Общение в чате позволяет решить многие вопросы, не отвлекая лектора. Чат, однако, может просматриваться лектором, и позволяет ему отвечать на вопросы слушателей. Это аналогично бумажкам с вопросами в очной форме чтения лекции. То есть в случае, если слушатель может кратко и четко сформулировать свой вопрос, он может задать его в чате, что занимает меньше времени, чем видеовопрос. Форум предназначен для общения аудитории и лектора вне сеансов чтения лекции. Например, если после прочитанной лекции, слушатель решил поглубже разобраться в материале, и обнаружил непонимание в каком-либо моменте, он может задать лектору или другим слушателям вопрос в специальной ветке форума, прикрепленной к данной лекции. Также в форуме могут задать вопрос пользователи, которые по каким-либо причинам не смогли прослушать онлайн лекцию, но смотрели копию, записанную в Интернет или на локальный носитель. При выполнении работы получены следующие основные результаты: • На основе анализа имеющихся систем и технологий, предназначенных для удаленного чтения лекций, обоснована актуальность разработки мультимедиа-лектория – специализированного продукта для чтения удаленных видеолекций, сопровождаемых сложным интерактивным и динамичным демонстрационным рядом и сформулированы требования к такой системе. 23

• Предложен оригинальный подход для построения мультимедиа-лектория, который основан на трансляции команд управления демонстрациями объектам на стороне слушателя. • Спроектирована архитектура системы на основе LCMS-системы с встроенным заменяемым коммуникационным модулем, что позволяет легко адаптировать систему под новые стандарты видеоконференцсвязи. • Разработаны методы, обеспечивающие расширяемость системы мультимедиа-лектория новыми типами демонстраций, предложен универсальный протокол. Определены и спроектированы наиболее востребованные типы демонстраций (тексты с графикой, видео, лекторская доска) и инструменты работы с ними (выделения текста, масштабирование и позиционирование графики, элементы управления видеозаписями, перо, указатель). • Спроектированы средства обратной связи мультимедиа-лектория – видеовопрос, тестирование, статистика слушателей, чат, форум. Реализована обратная связь в виде тестирования и видеовопросов. Реализованы средства сохранения лекции в Интернете и на локальном носителе. Система представлена Мультимедиа центром НГУ на сайте http://i-portal.nsu.ru и апробирована. В ходе работы было проведено несколько пробных сеансов чтения лекции из НГУ в Лейпцигском университете прикладных наук. Функциональность системы была протестирована в полном объеме и показала свою работоспособность. В результате выполнения проекта было выявлено, что система дистанционного чтения лекций с динамическим и интерактивным демонстрационным рядом – перспективное направление в развитии инструментария для образовательного процесса. Была выявлена принципиальная возможность создания мультимедиа-лектория на основе такой LCMS-системы как Инструментальный портал. Таким образом, в результате работы предложен путь создания эффективной системы дистанционного чтения лекций с видеосвязью и демонстрационным рядом. Работа выполнена при финансовой поддержке РФФИ (грант № 08-07-00229-а), РГНФ (грант №08-0312127в) и ФЦП «Научные и научно-педагогические кадры» госконтракт НК-50-6. Литература 1. 2. 3. 4. 5. 6.

7.

8.

Россия осваивает видеоконференцсвязь http://info.tatcenter.ru/society/10765.htm. Домашняя страничка продукта Microsoft NetMeeting http://www.microsoft.com/windows/netmeeting/. Домашняя страничка продукта Microsoft Windows Messenger http://join.msn.com/general/home. Домашняя страничка продукта Microsoft ConferenceXP http://www.conferencexp.net/community/default.aspx. Домашняя страничка продукта Skype http://www.skype.com. Е.В. Мозлов. Инструментальный портал создания и поддержки информационных ресурсов научного и образовательного характера / «Новые информационные технологии». Тезисы докладов XII Международной студенческой школы-семинара – М.: МГИЭМ, 2004, С. 338-340. В.Г. Казаков. Создание курсового обеспечения как информационных систем на основе баз данных учебных материалов, функционирующих в интернет/ИОЛ’99. Межд. конф. Тез. докл. Санкт-Петербург, 1999. С. 186-187. З.В. Баяндина, А.М. Задорожный, В.Г. Казаков, Н.В. Каменский, И.А. Лебедев. Организация информации в учебных ресурсах, построенных на базах данных: решение на основе метамодели данных. Вестник НГУ. Серия: Информационные технологии / Новосиб. гос. ун-т. Новосибирск, 2004. Т. 1. Вып. 2. С. 73–90.

АРХИТЕКТУРА ЭЛЕКТРОННОЙ СРЕДЫ ОБУЧЕНИЯ С ПРИМЕНЕНИЕМ ГЕТЕРОГЕННЫХ СЕТЕЙ ДЛЯ ДОСТУПА К ИНФОРМАЦИОННЫМ ОБРАЗОВАТЕЛЬНЫМ РЕСУРСАМ А.Г. Финогеев, В.А. Маслов, А.А. Финогеев Пензенский государственный университет E-mail: [email protected] Введение В настоящее время в связи со значительным прогрессом в развитии современных информационных и телекоммуникационных технологий образовательные учреждения различного профиля все большее внимание уделяют вопросам разработки и эффективного применения инновационных методик и технологий в процессе подготовки специалистов. При этом особую актуальность приобретают задачи, связанные с внедрением беспроводных информационно-телекоммуникационных технологий в вузе. В связи с появлением и развитием технологий электронного (e-learning) и мобильного (m-learning) образования возникает необходимость разработки систем произвольного персонального доступа как к внутренним информационно-образовательным ресурсам вуза, так и к внешним Интернет-ресурсам для поддержки различных форм очного и дистанционного обучения, самообразования студентов. 24

Труды конференции Телематика’2010

Для построения полнофункционального портала на основе гетерогенной телекоммуникационной среды помимо традиционных методов предлагается внедрить принцип «повсеместного» (ubiquitous) доступа к информационным ресурсам с поддержкой мобильности пользователей (технология u-learning). Концептуальное значение «повсеместная сеть» не ограничивается только географической характеристикой. Фактически это создание всеохватывающей (всепроникающей) телекоммуникационной сети, которая вместе с программным обеспечением позволяет реализовать концепцию получения информации по принципу 4А (“anywhere, anytime, by anyone and anything”). Подобный принцип предполагает широкое использование технологий беспроводной и мобильной связи (Bluetooth, Wi-Fi, Wimax, GPRS, EDGE, UMTS, WAP) [1]. Таким образом, возникает необходимость разработки широкомасштабных корпоративных информационных систем с возможностью беспроводного мобильного доступа пользователей к различным сервисам и ресурсам [2]. Причем подобная система должна предоставлять пользователю возможность обратной связи с информационной системой, Web-презентациями, виртуальными обучающими комплексами . К основным сервисам подобной информационной системы с беспроводным доступом можно отнести следующие: 1. Сервис локализации. Предназначен для обнаружения и идентификации мобильного устройства при его попадании в зоны доступа информационного пространства. 2. Сервис персональной информационной поддержки. Позволяет пользователю получать по запросу необходимую ему информацию. 3. Сервис сбора телеметрической и биометрической информации. Предназначен для мониторинга работы различных технических, энергетических, биологических и прочих систем в различных университетских службах. 4. Сервис дистанционного управления. Предназначен для использования мобильных устройств для управления приборами, объектами расширенной реальности [3] и т.д. 1. Архитектура информационной сети с поддержкой беспроводного доступа Для реализации проекта предложена базовая архитектура гетерогенной сети с объединением сетей трех беспроводных технологий и проводного сетевого сегмента Ethernet со шлюзами во внешнюю Интернет сеть, доступом в сети. В общем случае сетевая архитектура включает следующие кластерные сегменты: • Кластеры сенсорных узлов ZigBee. • Распределенную структуру (scatter net) пикосетей устройств связи с радиомодулями Bluetooth. • Зоны доступа WiFi с расширенным набором базовых служб (ESS-topology). • Совокупность устройств, используемых для беспроводного доступа к ресурсам гетерогенной сети. • Совокупность интерфейсных устройств (маршрутизаторов, координаторов и т.д.), выполняющих функции шлюзования для объединения сегментов и выхода во внешнюю сеть. Для объединения устройств внутри кластера используются координаторы, точки доступа, мастерузлы, маршрутизаторы и коммутаторы. Для объединения кластеров разных технологий используются устройства-шлюзы (мосты) с несколькими беспроводными модулями и программным обеспечением для протокольного преобразования. 2. Идентификация и локализация в информационном пространстве При организации «повсеместного» доступа к информационным ресурсам университета первоочередной задачей является идентификация и аутентификация пользователей, а также локализация (определение местоположения) их устройств с модулями беспроводного доступа в зонах доступа к информационным ресурсам с целью ограничения несанкционированного доступа и выполнения требований политики безопасности университетской сети [6]. Разработка данных методов определения местоположения клиентского оборудования беспроводной связи является одной из важных проблем применения технологий беспроводных сетей. С одной стороны, это позволяет владельцу мобильного устройства с требуемой точностью обнаружить свое местоположение на карте или плане здания или рассчитать положение мобильного устройства относительно других устройств. С другой стороны, позволяет создать точки привязки мобильных устройств с модулями беспроводной связи к координатам местности. 3. Методология позиционирования и локализации мобильных объектов Разработка систем позиционирования мобильных и стационарных узлов с высокой точностью в помещениях с использованием базовых станций и мобильных узлов разных беспроводных сегментов является актуальной научно-исследовательской задачей. Методология, как правило, должна включать совокупность методик и технологий, которые могут применяться как по отдельности, так и в комбинации друг с другом. В частности разработанная методология позиционирования и локализации мобильных объектов в беспроводной гетерогенной сети включает: • Математические модели для решения задачи позиционирования. • Модели и методику калибровки эмпирической модели затухания радиосигнала с учетом особенностей строительных конструкций в зонах позиционирования. 25

• Методику позиционирования в беспроводных сегментах WiFi на основе измерения уровня сигнала RSSI (Received Signal Strength Indication) (рис. 1). • Методику позиционирования в беспроводных сегментах Bluetooth на основе измерения уровня сигнала RSSI. • Методику позиционирования в сенсорных сетевых сегментах ZigBee на основе измерения уровня сигнала RSSI и времени распространения сигнала. • Методику улучшения точности позиционирования на основе привязки к координатам глобальной навигационной системе.

Рис. 1. Локализация в сетях WiFi Конечными результатами работы методов позиционирования является не только определение местоположения мобильного клиента, а его идентификация и реакция различного оборудования при попадании мобильного узла в определенные области. Поэтому в проекте разрабатывается не просто методика определения местоположения, а методология поддержки принятия решения при обнаружении и локализации мобильного узлов, включающая способы активации устройств, сенсорных узлов, программно-информационных систем и виртуальных объектов, а также поддержки методики слежения за передвижениями мобильных узлов (tracking) с реагированием на их перемещения. Методика измерения расстояний на основе уровня принимаемого сигнала применяется с сетевых сегментах беспроводных технологий стандартов IEEE 802.11, IEEE 802.15.1 и IEEE 802.15.4, так как все передатчики данных стандартов аппаратно поддерживают возможность измерения параметра RSS. Оценка расстояния происходит с учетом соотношения: P(d) = P(d0) – 10nlog10(d/d0) [дБм], где P – уровень принимаемого сигнала в децибелах относительно милливатта, дБм, n – коэффициент ослабления сигнала. Для оценки расстояния в процессе локализации в двумерной системе координат необходимо проводить позиционирование, по крайней мере, относительно трех базовых станций [9] методом триангуляции. Наилучшие же измерения можно сделать путем привязки локальной системы координат к глобальной навигационной системе путем установки одной станции в здании с GPS/ГЛОНАСС модулем и выносной приемной антенной, что и предполагается сделать в процессе создания системы глобального позиционирования. В реальных условиях число «видимых» базовых станций в зоне локализации при перемещении мобильного узла представляет собой случайную величину, поэтому необходимо использовать методику улучшения точности позиционирования для преобразования опорных векторов позиционирования относительно точек привязки к координатам глобальной навигационной системы типа NAVSTAR (GPS) или ГЛОНАСС. Для повышения точности позиционирования представляется возможным использовать калиброванную эмпирическую модель затухания радиоволн с учетом особенностей строительных конструкций конкретного здания, калибровка которой производится экспериментальным способом в процессе настройки системы позиционирования. Другой вариант повышения точности – использовать 26

Труды конференции Телематика’2010

«отпечатки» всего множества измеренных в точке значений RSS для поиска наиболее схожего образца «отпечатка» среди созданных при калибровке системы вместо определения расстояний до базовых станций. 4. Экспериментальная гетерогенная среда с беспроводным доступом к информационным ресурсам Разработка гетерогенного пространства в данном случае предполагает использование беспроводных сетевых устройств, работающих в одном частотном диапазоне, но использующих разные стандарты передачи цифровой информации. В настоящее время на рынке представлены в большинстве устройства, работающие в диапазоне 2,4 ГГц, которые позволяют строить беспроводные сетевые сегменты трех основных категорий: • Локальные офисные сети WiFi стандартов IEEE 802.11 b/g/n. • Персональные сети Bluetooth стандарта IEEE 802.15.1. • Сенсорные сети ZigBee стандарта IEEE 802.15.4. Так как в большинстве российских вузов уже развернуты и эксплуатируются сети технологии Ethernet, то целесообразно объединять беспроводные сетевые сегменты на основе данной Ethernet сети, которая будет выполнять роль магистрали, а беспроводные сегменты – роль подсетей доступа для мобильных абонентов и подсетей мониторинга технических объектов. Тогда для беспроводных сегментов роль интерфейсных шлюзов будут выполнять: • Точки доступа и маршрутизаторы WiFi для ячеек IEEE 802.11 b/g/n. • Точки доступа Bluetooth для пикосетей IEEE 802.15.1. • Координаторы ZigBee для кластеров IEEE 802.15.4. Рассмотрим основное оборудование, которое использовано на кафедре «Системы автоматизированного проектирования» и в центре дистанционного образования (ЦДО) Пензенского государственного университета (близко расположенных) для построения беспроводных сегментов гетерогенной сети с двумя основными функциями: • Поддержка беспроводного доступа с мобильных устройств студентов в кафедральное и университетское информационное пространство и выхода во внешний оптоволоконный Интернет канал посредством технологий WiFi (802.11g/n) и Bluetooth (802.15.1). • Выполнение интегративной функции, т.е. поддержка шлюзования при объединении разных сегментов на базе единой университетской Ethernet сети. При этом оборудование Bluetooth и WiFi является интерфейсом для обеспечения доступа к информационным ресурсам, поддержки технологий идентификации и позиционирования пользователей сети, а оборудование ZigBee – интерфейсом для сбора телеметрической информации с технических, охранных и пожарных систем, систем доступа и радиоидентификации мобильных узлов, систем слежения и т.д. 4.1. Сегмент беспроводного доступа на базе технологии WiFi Для построения беспроводного WiFi сегмента на кафедре САПР и в ЦДО Пензенского государственного университета был выбран маршрутизатор ASUS WL-500W, поддерживающий стандарт IEEE 802.11b/g/n с возможностью передачи данных на скорости до 300 Мбит/с. Маршрутизатор установлен таким образом, чтобы обеспечить покрытие территории всей кафедры и ЦДО университета. Тестирование работы мобильных устройств в зоне доступа маршрутизатора показало, что даже в худшем случае, в отдаленных аудиториях с перекрытиями в три стены мощность достаточна для успешного подключения. Устройство было настроено на режим работы точки доступа без выполнения функций маршрутизации. Кафедральная точка доступа была настроена таким образом, чтобы не создавать помех ближайшим университетским точкам доступа. На точке доступа включен встроенный DHCP-сервер, который позволяет автоматически подключать мобильные устройства пользователей с выделением адресов. 4.2. Сегмент беспроводного доступа на базе технологии Bluetooth Идея организации доступа к информационным ресурсам не только по сети WiFi по и на основе пикосетей Bluetooth обоснована тем, что основные модели мобильных телефонов имеет данный радиомодуль, подавляющее большинство студентов использует такие сотовые телефоны, а не устройства в которых есть WiFi радиомодуль [7]. Для организации зоны Bluetooth доступа для мобильных клиентов было выбрано устройство D-link DBT-900AP. Точка доступа является решением по беспроводному доступу множества студентов к информационным образовательным ресурсам через пикосеть Bluetooth. Преимуществом ее использования являются небольшая цена и «прозрачность» с точки зрения подключения к проводной среде. При ее установке не требуется специальных драйверов и выполнения сложных сетевых настроек. Точка доступа позволяет подключаться к кафедральной и университетской сети для доступа к учебно-методическим ресурсам. Таким образом, позволяя использовать для этого устройства с модулями Bluetooth связи, такие как сотовые телефоны, коммуникаторы, смартфоны и КПК. Система предполагает событийное управление различными сценариями поведения для совершения заранее предопределенных действий в зависимости от определения местоположения мобильного Bluetooth устройства. Эта технология может быть также использована в музеях для предоставления 27

посетителям различной информации о музейных артефактах [8], рядом с которыми посетитель находится в данный момент времени (рис. 2).

Рис. 2. Информационная поддержка посетителей в Ethernet-Bluetooth сети 4.3. Сегмент беспроводного доступа на базе технологии ZigBee Сегодня на рынке присутствует широкий спектр оборудования для построения сетей с использованием технологии Zigbee. Для проведения научных исследований студентами и аспирантами и созданию экспериментальных кластерных сегментов различного назначения на кафедре САПР ПГУ используются сетевые отладочные комплекты от ведущих производителей данного оборудования. В частности с помощью комплектов моделируются и исследуются возможности создания следующих служб, сервисов и систем на основе сенсорных сетей: • Управление мобильными группами оперативно-тактического назначения в автономных самоорганизующихся сетях. • Беспроводные системы оперативного диспетчерского управления, системами ЖКХ и другими системами промышленной автоматики на примере сетей тепло-, водо-, и энергоснабжения в городских условиях. • Службы мониторинга (биологического, медицинского, технического, экологического и т.д.) в информационных инфраструктурах территории. • Создание систем распределенной обработки информации в самоорганизующихся кластерных сегментах с децентрализованным механизмом управления. Для создания экспериментального гетерогенного информационного пространства с элементами «повсеместной» сенсорной сети используются отладочные комплекты сенсорных сетей: • Комплект фирмы JENNIC (JN5139-EK010). • Комплекты фирмы Digi (Xbee-PRO 868). • Комплект фирмы Telegesis (ETRX2). • Комплект фирмы Texas Instrument (EZ430-RF2480). Все названные комплекты предоставляют полную среду для быстрой разработки беспроводных приложений и подключения различных датчиков и приборов. Библиотеки, предусмотренные стандартом IEEE 802.15.4 и спецификацией ZigBee, поддерживают различные топологии сенсорных сегментов (звезда, дерево, шина и ячеистая сеть) с централизованным и децентрализованным механизмом управления информационным трафиком, и обеспечивают самоорганизацию при активации узлов и самовосстановление функциональных возможностей сети для надежной связи при отказе узлов. Заключение На сегодняшний день экспериментальная гетерогенная сеть с поддержкой различных вариантов беспроводного доступа к информационным ресурсам введена в опытную эксплуатацию на кафедре САПР ПГУ и центра дистанционного образования. Информационная система сеть обеспечивает студентов с мобильными средствами связи и компьютерами возможностью бесплатного получения учебно-методических материалов, лицензионных программных дистрибутивов и прочей информации, хранящихся на серверах кафедры и ЦДО с различных мобильных устройств в любое время и в любых аудиториях, находящихся в зонах уверенного приема. Также обеспечивается шлюз для выхода в университетскую сеть для доступа к ресурсам других кафедр и подразделений и выход во внешний 28

Труды конференции Телематика’2010

Интернет. В зависимости от устройств пользователя сеть обеспечивает возможность подключения по проводному Ethernet соединению, по беспроводным Bluetooth и WiFi каналам, и даже модемное подключение мобильных средств связи к сегментам экспериментальной сенсорной сети в процессе выполнения лабораторных и практических работ. Поддерживается возможность передачи информации между протокольными стеками разных подсетей на основе IP маршрутизации для организации принципа 4А «повсеместного» (ubiquitous) доступа к информационным ресурсами с поддержкой мобильности пользователей. Все оборудование и информационные сервисы предоставляются студентам и преподавателям на бесплатной основе для самообразования, подготовки и проведения учебных занятий, доступа к электронным учебникам и обучающим комплексам, виртуальным лабораториям, образовательным порталам, для оценки знаний обучаемых по технологиям дистанционного тестирования. Даже для ведения лекционных занятий с поддержкой беспроводных технологий используется проекторное оборудование с WiFi модулями радиосвязи, которое предоставляет возможность беспроводного подключения к мобильным устройствам преподавателей и серверам кафедры, для лекционных презентаций и демонстраций новых возможностей образования. Такие занятия уже ведутся по дисциплинам информационно-вычислительного профиля (Computer Science), например, в рамках курсов и телекоммуникации», «Сетевые технологии», «Информационные сети», «Сети ЭВМ «Администрирование информационных систем», «Мультимедийные технологии», и т.д. Основной целью является реализации на практике новых технологий мобильного (m-learning) образования и подготовки к внедрению технологий «повсеместного» (u-learning) образования будущего на основе беспроводных «всепроникающих» сетей следующего поколения. Литература 1. Финогеев А.Г. Беспроводные технологии передачи данных для создания систем управления и персональной информационной поддержки / Обзорно-аналитическая статья по приоритетному направлению "Информационно-телекоммуникационные системы", 2008. – 51 с. URL: http://window.edu.ru/window/ library?p_rid=56177. 2. Финогеев А.Г., Маслов В.А., Финогеев А.А. Перспективные исследования в области создания мобильных систем управления и персональной информационной поддержки // Труды 35 Междунар. конф. Информационные технологии в науке, образовании, телекоммуникации и бизнесе (IT+S&E'08) (Майская сессия) // прил. к журн. Открытое образование. – Украина, Крым, Ялта-Гурзуф, 20-30 мая, 2008. – С. 169-172. 3. A. Finogeev «System of the removed management 3D-presentations for virtual museums and galleries» // EVA 2006 Florence; Cappellini,Vito; Hemsley, James (2006) (Eds.): Electronic Imaging & the Visual Arts. Proceedings of the EVA 2006 conference, April 3-7, Florence, Italy. – C. 93-99. 4. Финогеев А.Г. Моделирование исследование системно-синергетических процессов в информационных средах: Монография, Пенза: Изд-во ПГУ, 2004, 223 с. 5. S. Ganu, S. Zhao, L. Raju, B. Anepu, I. Seskar, and D. Raychaudhuri, “Architecture and prototyping of an 802.11-based self-organizing hierarchical ad-hoc wireless network (SOHAN),” International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2004), September 2004. 6. Маслов В.А., Финогеев А.Г. Локализация в беспроводных сетях // Надежность и качество // В сб. трудов междунар. симпозиума. – Пенза: Изд. ПГУ, 2009 г., т. 1, – С. 234-237. 7. Финогеев А.Г., Кувшинников Д.А., Маслов В.А., Финогеев А.А. Построение информационного пространства вуза с использованием беспроводной технологии Bluetooth // Прикладная информатика. – Москва: Изд. Маркет DS, 2008. – № 6(18). – С.101-109. 8. Alexey. G. Finogeev, Vladinir A. Maslov, Anton A. Finogeev, Kirill A. Bukin «Interactive system for information support museum visitors on base Bluetooth technologies» // EVA 2008 Florence; Cappellini,Vito; Hemsley, James (2008) (Eds.): Electronic Imaging & the Visual Arts. Proceedings of the EVA 2008 conference, April 16-18, Florence, Italy: Le Officine Grafiche Technoprint, Bologna, 2008, ISBN 88-371-1676-4. – c. 152-157. 9. Резников, М.Б. Геолокация в сотовых сетях с использованием трех базовых станций // Резников М.Б. / Труды Научной конференции по радиофизике. Изд. НГГУБ, Нижний Новгород. 2005. С. 202.

МОДЕЛИРОВАНИЕ МЕХАНИЗМОВ QOS В КОММУТАТОРАХ ETHERNET ЦВЕТНЫМИ СЕТЯМИ ПЕТРИ А.Л. Домнин, Е.А. Кизилов, В.А. Пушкарев Пензенский государственный университет E-mail: [email protected] Механизмы обеспечения качества обслуживания (QoS) занимают одно из важнейших мест в арсенале современных технологий сетей с коммутацией пакетов, так как без их применения невозможна передача мультимедийных данных (потокового видео, звука и др.) [1, 2]. В целях оценки эффективности различных методов QoS предлагается использовать модели телекоммуникационных устройств. В настоящей работе проводится разработка модели коммутатора Ethernet с поддержкой QoS на основе цветных иерархических временных сетей Петри. 29

В настоящей работе основное внимание уделяется моделированию механизмов обеспечения QoS: введение классов обслуживания для различных видов трафика, алгоритмы управления очередями. Идея, лежащая в основе методов обеспечения QoS, – каждый ресурс (процессорное время, размеры буферов и др.) должен быть разделен между разными классами трафика по определенным правилам. Это позволяет по-новому взглянуть на проблему организации сетей передачи данных: не только с точки зрения топологии, но и с точки зрения обеспечения качества обслуживания. Объектом моделирования выступает коммутатор Ethernet, поддерживающий стандарт IEEE 802.1pq, позволяющий реализовывать транспортную среду мультисервисных сетей передачи данных [3]. В качестве инструмента для построения и исследования моделей используется система CPN Tools [4]. Выбор в качестве системы моделирования CPN Tools обусловлен его гибкостью, широкими возможностями. Сети Петри представляют собой универсальную алгоритмическую систему, позволяющую описывать произвольные объекты. Свойства «цвета» позволяют описывать алгоритмы обработки, зависящие от параметров трафика (адреса, размеры, теги и др.). Иерархичность позволяют строить сложные многокомпонентные модели. Свойство времени обеспечивает возможность моделирования динамических характеристик объекта (например, задержку). При разработке моделей использовалась методология нисходящего проектирования: была разработана и исследована иерархическая модель коммутатора, верхний уровень которой представляет традиционную структурную схему коммутатора, состоящую из входных/выходных портов, блока коммутации, буферов [5]. Введение иерархий было вызвано необходимостью в структуризации модели и в создании нескольких уровней детализации различных её компонентов. Модель (рис. 1) представляет собой иерархическую структуру, в которую входят модели входных/выходных портов, буферов, блоков коммутации [6].

Рис. 1. Структура 4-х портового коммутатора. Верхняя иерархия Трафик моделируется последовательностью маркеров, поступающих во входные порты и исходящих из выходных портов, цвета которых образуют кортеж полей, соответствующих формату кадров Ethernet 802.1pq: mac-адреса источника и приемника, поле типа/размера, контрольная сумма, поле тега с информации о принадлежности VLAN и определенному уровню приоритета. Также было добавлено служебное поле delay, хранящее время обработки кадра в коммутаторе, которое используется для сбора статистики и анализа работы модели. Кроме того, вводятся маркеры, цвета которых отражают 30

Труды конференции Телематика’2010

служебные характеристики модели. Для описания цветов, переменных и функций используется язык CPN ML [4]: • INT – стандартный цвет, представляющий целое число; • MAC=INT with 1..10 timed – цвет, который представляет MAC адрес, является целым числом из диапазона; • col=INT timed – цвет, представляющий целое число с параметром времени; • QoS=int with 1..4 – цвет, представляющий уровень качества обслуживания, является целым числом из диапазона; • frm=product MAC*MAC*QoS*INT*INT timed – сложный цвет, представляющий содержание передаваемого кадра; • frame=union f:frm + avail timed – сложный цвет, представляющий наличие или отсутствия кадра; • Size=INT with 80..1500 – цвет, представляющий размер данных в кадре; • TIMED=INT timed – цвет, представляющий целое число с параметром времени; • Lbuffer=list frm – цвет, который представляет собой список маркеров цвета frm. Переменные, используемые в модели: • var szfrm: Size – переменная цвета Size, содержащая размер данных, содержащихся в поле данных кадра; • var sz1, sz2, sz3, sz4: INT – переменные цвета INT, которые содержат размер информации, находящейся в буфере очереди; • var i, j, k: INT – служебные переменные цвета INT; • var delay: INT – переменная цвета INT, содержащая значение задержки; • var src: MAC – переменная цвета MAC, содержащая адрес источника; • var dst: MAC – переменная цвета MAC, содержащая адрес назначения; • var qos: QoS – переменная цвета QoS, которая содержит требуемый уровень качества обслуживания; • var fr: frm – переменная цвета frm, содержащая кадр, используемая для работы со списком маркеров цвета frm; • var mtime: TIMED – переменная цвета TIMED; • var lbuf: LBuffer – переменная цвета LBuffer, которая содержит список маркеров цвета frm, находящихся в очереди; • var lbuf2: LBuffer – переменная цвета LBuffer, содержащая список маркеров цвета frm, которые отбрасываются, если очередь переполнена; • var f1, f2 ,f3, f4: frame – переменные цвета frame, используемые при формировании выходного трафика. Функции, используемые в модели: • fun SetMAC() = MAC.ran() – функция, которая выбирает случайное число из диапазона, описанного цветом MAC. Используется в генераторе трафика для задания mac-адреса при создании кадра; • fun SetQoS() = QoS.ran() – функция, выбирающая случайное число из диапазона, описанного цветом QoS. Используется в генераторе трафика для задания значения поля QoS при создании кадра; • fun SetSize() = Size.ran() – функция, которая выбирающая случайное число из диапазона, описанного цветом Size. Используется в генераторе трафика для задания значения поля szfrm при создании кадра; • fun GetTime() = IntInf.toInt(time()) – функция для получения текущего модельного времени; • fun GetDelay_NoiseTraf() = poisson(20000) – функция, определяющая длительность межкадрового интервала «шумового» трафика. • fun GetDelay_UsefulTraf() = poisson(50000) – функция, определяющая длительность межкадрового интервала трафика, который подмешивается к исследуемому трафику. Входные и выходные порты представляют собой сети Петри, моделирующие прием/передачу маркеров через полнодуплексный интерфейс. В качестве модели коммутационного блока, передающего кадры с входного порта на определенный выходной порт, была использована сеть Петри, предложенная в [7, 8], в которой выполняется перенаправление маркера (кадра) в соответствии с таблицей коммутации. Алгоритмы управления очередями реализуются в буферах выходных портов. Они используются для минимизации потерь пакетов в периоды временных перегрузок, когда сетевое устройство не справляется с передачей пакетов на выходной интерфейс в темпе их поступления. Какие пакеты будут переданы на выходной порт, это зависит от конкретного алгоритма и от класса трафика, к которому принадлежит пакет. Реализация заключается в разделении буфера на несколько очередей, каждая из которых предназначена для трафика определенного класса, генерируемых приложениями с определенной чувствительностью к задержкам и потерям пакетов (асинхронный, изохронный, реального времени). Сеть Buf (рис. 1) является моделью буфера выходного порта и включает в себя подсети, реализующие основные механизмы QoS:

31

• Classifier – классификатор типа пакета, который выделяет из последовательности пакетов, поступающих в буфер, пакеты, имеющие общие требования к качеству обслуживания. Классификация выполняется на основе содержимого поля qos (соответствует полю Quality кадра Ethernet 802.1pq). • Queue – очередь типа FIFO, буферизирующая кадры одного класса. В этой подсети также реализованы подсчет размера текущего содержимого буфера и отбрасывание поступивших кадров при переполнении буфера. Эти данные используются по окончании моделирования для анализа работы модели. • MUX – сеть, реализующая один из алгоритмов обслуживания очередей различных классов и управление полосой пропускания, выделяемой для каждого из классов трафика. На рис. 2 изображен «срез» модели буфера – сети, через которые проходит маркер цвета frm (кадр Ethernet) перед тем как попасть в выходной порт коммутатора. Классификатор (сеть Classifier) на основании содержимого поля qos кадра, направляет его в определенную очередь (сеть Queue). Перед тем, как поместить кадр в очередь, производится проверка на наличие свободного места (переход Insert). Если места достаточно, то кадр помещается в очередь типа FIFO (переход в позицию Queue), в противном случае – отбрасывается (переход в позицию Garbage). В позиции Queue находится маркер с цветом list frm, с помощью которого формируется список маркеров (кадров), подходящий для реализации модели очереди типа FIFO. В позиции Size находится маркер, в котором хранится суммарный размер фреймов на текущий момент времени. После перехода маркера (кадра) в позицию Queue его размер (значение поля szfrm) прибавляется к значению маркера в позиции Size. Кадры, помещенные в очередь, в порядке поступления освобождают её и отправляются в блок регулирования полосы (сеть LineReg). Назначение данной сети заключается в том, что необходимо выделить для трафика каждого уровня приоритета определенную часть от общей полосы пропускания. И не имеет значения, какой алгоритм обслуживания очередей при этом используется. Регулирование полосы пропускания реализуется по алгоритму «дырявого ведра». В позиции Limit хранится значение, описывающее ограничение пропускной способности полосы для трафика данного приоритета. В позиции Bits_Passed, которая связана также с сетью, реализующей алгоритм обслуживания очередей и формирование выходного трафика (сеть MUX), хранится значение объема трафика, пропущенного на выходной порт в конкретный момент времени. Сброс в ноль значения, хранящегося в позиции Bits_Passed, производится по внешнему таймеру (на рисунке не показан). При поступлении кадра на вход блока регулирования полосы (сеть LineReg), происходит сравнение объема пропущенных кадров (значение маркера в позиции Bits_Passed) и лимита полосы (значение маркера в позиции Limit). Кадр поступает в блок формирования выходного трафика (сеть MUX) при условии, что значение переданного на текущий момент трафика не превышает значение лимита, выделенного для этого приоритета. Модели блоков обслуживания очередей и формирования выходного трафика отличаются в зависимости от алгоритма обслуживания очередей. Были разработаны сети, реализующие наиболее распространенные алгоритмы обслуживания очередей: приоритетное обслуживание, взвешенное обслуживание, справедливое (комбинированное) обслуживание. На рис. 2 изображены блок приоритетного обслуживания очередей и формирования выходного трафика (переход Priority) и блок взвешенного обслуживания очередей и формирования выходного трафика (переходы Frame Valve и Avail Valve). Блок справедливого (комбинированного) обслуживания на рис. 2 не показан. Он формируется комбинацией приоритетного обслуживания для определенных классов трафика с взвешенным обслуживанием для остальных классов. В случае приоритетного обслуживания, перед отправкой кадра в выходной порт выполняется проверка (переход Priority) доступности выходного порта (маркер avail в позиции out), а также отсутствие кадров в очередях с более высоким приоритетом (f1…fi-1). После того, как кадр перешел в выходной порт значение в позиции Bits_Passed увеличивается на размер только что пропущенного кадра (значение поля szfrm). Также освобождается место в очереди (уменьшается на значение szfrm текущий размер очереди в позиции Size). Иначе работает блок обслуживания очередей и формирования выходного трафика в случае взвешенного обслуживания. При работе взвешенных очередей используется механизм сканирования, то есть последовательный опрос всех очередей на наличие фреймов. Номер опрашиваемой очереди хранится в состоянии Next Scan. Для обеспечения работы механизма сканирования используются два перехода, первый (переход Frame Valve) отвечает за передачу кадра, второй (переход Avail Valve) – обеспечивает переключение на сканирование следующей очереди. При отправке кадра в выходной порт (переход Frame Valve) выполняется проверка доступности выходного порта и соответствия порядкового номера текущей очереди значению, хранящемуся в состоянии Next Scan. После того, как кадр перешел в выходной порт значение в позиции Bits_Passed увеличивается на размер только что пропущенного кадра (значение поля szfrm). Также освобождается место в очереди (уменьшается на значение szfrm текущий размер очереди в позиции Size). Кроме того, в состояние Next Scan заносится порядковый номер следующей очереди, которая будет просканирована следующей. Если очередь не содержит кадров, то при доступности выходного порта и наличии кадра в любой другой очереди (f1…fi-1) срабатывает переход Avail Valve, задавая номер следующей сканируемой очереди.

32

Труды конференции Телематика’2010

33

Справедливое (комбинированное) обслуживание является широко распространенной группой алгоритмов обслуживания очередей. В наиболее популярном алгоритме подобного рода имеется одна приоритетная очередь для чувствительного к задержкам трафика и несколько очередей для эластичного трафика нескольких классов, которые обслуживаются по взвешенному алгоритму. В ходе работы была разработана модель, реализующая комбинированное обслуживание очередей по описанному выше алгоритму. Временная характеристика коммутатора моделируется задержкой прохождения маркера (кадра) при срабатывании выходного перехода в сети Петри выходного порта. Задержка задается суммой составляющих: • коммутации – длительность зависит от скорости срабатывания микросхем в блоке коммутации и обычно имеет постоянное значение ( TC ); • в очереди – длительность зависит от времени нахождения кадра в очередях коммутатора ( TQ ); • в выходном порту (сериализации) – длительность зависит от переменной составляющей (размера фрейма) ( TF ) и постоянных составляющих (преамбула и межкадровый интервал) ( TO ). Для испытания и анализа модели коммутатора были разработаны модели, которые реализуют генерацию трафика с определенными характеристиками и необходимым законом распределения интервалов задержек между кадрами. В модели предусмотрены измерительные фрагменты, обеспечивающие накопление статистики сброса кадров при переполнении очереди, текущей длины очереди, а также задержек при обработке кадров в коммутаторе. Отдельно разработаны: • генератор трафика (сеть Петри, генерирующая маркеры (кадры) с заданными характеристиками для имитации входного трафика); • программа сбора статистических данных по лог-файлу работы модели. Статистическая обработка данных выполняется с помощью пакета MS Excel или OpenOffice.org Calc. Некоторые результаты моделирования сети приведены в таблице 1. Приоритетный трафик (qos = 1) является композицией двух потоков: регулярного (с периодом следования в 3 мс) и пуассоновского (со средним временем – 6 мс). Трафик остальных классов QoS (qos = 2..4) формировался разделением на 3 потока из кадров со средним периодом следования в 2 мс. Длина кадров пуассоновских потоков задавалась с полезной нагрузкой равномерно распределенной в интервале от 80 до 1500 байт, размер полезной нагрузки кадров регулярного трафика – 200 байт. Таблица 1. Класс QoS

Полоса, %

Коэффициент загрузки полосы

Среднее время задержки в очереди (мс)

Потерянные пакеты (%)

1

20

0,87

2,51

0

2

40

0,30

1,15

0

3

30

0,36

0,55

0

4

10

1,03

77,82

4,2

Общий трафик

100

0,56

13,79

0,6

Из таблицы видно, что выделенной приоритетное обслуживание трафика класса 1 неэффективно ввиду очень высокой загрузки выделенной полосы, поэтому приоритет не дает каких-либо преимуществ с точки зрения сокращения задержек и их вариаций (джиттера). Трафик класса 4 перегружает выделенную полосу пропускания (эффект некоторого превышения заданной полосы пропускания объясняется тем, что реализуемый алгоритм управления полосой позволяет использовать незанятые полосы других классов). Большую информацию о трафике можно получить с помощью анализа графиков профилей трафика, гистограмм задержек и длительности очередей. Выводы по работе: • отработана методика моделирования механизмов QoS цветными иерархическими сетями Петри; • разработана модель коммутатора, позволяющая оценить вероятностно-временные характеристики трафика и динамику использования буферов; • разработанные модели можно использовать в качестве компонентов модели локальной сети передачи данных со сложной топологией; • отдельные подсети модели могут быть применены для моделирования работы протоколов других уровней (например, IP-маршрутизаторов). Литература 1. 2. 34

Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 3-е изд. – СПб.: Питер, 2008. Гугель Ю.В. Характеристики параметров "Качество обслуживания" опорной инфраструктуры научно-образовательной сети // Информатизация образования и науки, 2009, Вып. 4.

Труды конференции Телематика’2010

3. 4. 5.

6. 7. 8.

Филимонов А.Ю. Построение мультисервисных сетей Ethernet. – М.: BHV, 2007. Kurt Jensen, Lars M. Kristensen. Coloured Petri Nets: modelling and validation of concurrent systems. – Springer, 2009. Механов В.Б. Применение сетей Петри для моделирования механизмов обеспечения QoS в компьютерных сетях // Материалы международного симпозиума “Новые информационные технологии и менеджмент качества (NIT&MQ’2010)” ФГУ ГНИИ ИТТ “Информика”.- М.: ЭГРИ, 2010 Домнин А.Л., Кизилов Е.А., Пушкарев В.А. Моделирование интеллектуальных коммутаторов Ethernet сетями Петри // Микроэлектроника и информатика -2010. – М.: МИЭТ, 2010. Zaitsev D.A. Switched LAN Simulation by Colored Petri Nets // Mathematics and Computers in Simulation. – 2004. – Vol. 65, № 3. Зайцев Д.А., Шмелёва Т.Р. Моделирование коммутируемой локальной сети раскрашенными сетями Петри // Зв'язок, 2004, № 2(46).

РАЗРАБОТКА СИСТЕМЫ МОНИТОРИНГА КОМПЬЮТЕРНОЙ СЕТИ RUNNet Г.А. Карапетян Санкт-Петербургский государственный университет информационных технологий механики и оптики E-mail: [email protected] Сегодня фактически любая отрасль информационных технологий в значительной степени опирается на использование компьютерных сетей. Компьютеров, как и информации, необходимой для передачи, с каждым годом становится все больше, что заставляет постоянно развиваться и модернизироваться компьютерные сети. Сети активно развиваются и расширяются, их масштабы и объемы передаваемого трафика постоянно растут, что, в свою очередь, обуславливает необходимость разработки надежных и удобных в использовании систем мониторинга и управления компьютерными сетями. Основной задачей таких систем является постоянное наблюдение за состоянием сети, выявление сбоев и неполадок в ее работе и незамедлительное сообщение об обнаруженных ошибках обслуживающему персоналу сети. Кроме этой основной цели любой системы мониторинга, в разных сетях встает необходимость решать и другие задачи, которые могут заметно отличаться по функциональности, а иногда и вовсе быть взаимоисключающими. На сегодняшний день существует достаточно большое количество систем и приложений, осуществляющих мониторинг как локальных, так и глобальных компьютерных сетей. Каждая из таких систем имеет свои достоинства и недостатки, причем в большинстве случаев этими недостатками являются слишком большие ресурсные затраты на их внедрение, освоение и использование, а также возможные проблемы в работе системы, возникающие при изменениях структуры компьютерной сети. В настоящей статье рассматривается реализованная автором собственная система мониторинга глобальной компьютерной сети, которая, при относительно малых ресурсных затратах, позволяет создать полноценную, наглядную модель сети, полностью отображающую ее структуру и состояние в режиме реального времени. В задачи данной системы входит также проверка работоспособности всех узлов сети, с сообщением системному администратору об обнаруженных сбоях и ошибках в ее работе. На начальном этапе разработки системы мониторинга необходимо было определиться со способом визуализации работы компьютерной сети. Учитывая специфику глобальных компьютерных сетей (в частности, большое расстояние между узлами) и желание создать максимально наглядную и полную модель, в качестве основного компонента системы визуализации использовалась географическая карта Google Map (http://maps.google.com). Этот весьма популярный веб-сервис компании Google был выбран не случайно – данные географические карты предлагают большое количество полезных функций и возможностей. Немаловажную роль при выборе геосистемы для визуализации работы компьютерной сети сыграла и открытость кода данного приложения, что позволяет относительно легко вносить в него изменения путем интегрирования собственных JavaScript-сценариев. Компьютерная сеть в разработанной системе представляется в виде набора узлов и соединений между ними. Эти наборы, в свою очередь, могут делиться на какие-либо подмножества, в зависимости от структуры конкретной сети. Элемент компьютерной сети (узел или соединение между узлами) характеризуется заданным набором параметров, при помощи которых система однозначно идентифицирует данный элемент и организует его связь с другими элементами сети. Система полностью ориентирована на использование свободно распространяемого программного обеспечения. В частности, для хранения и обработки информации об элементах сети используется база данных MySQL. Разработанная и используемая в системе база данных включает в себя три взаимосвязанных таблицы, в которых находится вся необходимая информация для создания модели сети. Первая таблица, служащая для хранения данных об узлах сети, состоит из 9 полей, в каждом из которых хранится тот или иной параметр узла: тип, имя, географические координаты, адрес веб-страницы, IP-адрес, дополнительная информация, состояние узла и его идентификатор. Вторая таблица хранит данные о соединениях между узлами и содержит 4 поля: идентификаторы двух соединяемых узлов, ссылка на веб-ресурс с информацией о данном соединении и идентификатор соединения. Третья таблица базы данных 35

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

Рис. 1. Веб-форма для изменения информации об узле компьютерной сети Взаимодействие с веб-сервером в системе происходит через CGI-интерфейс на основе специальных скриптовых программ, написанных на языке Perl. Вся информация из веб-форм перед занесением в базу данных проходит автоматическую проверку (в основном, в целях безопасности), после чего происходит ее добавление в базу данных. Выполненное на данном этапе разработки занесение в базу данных информации об узлах сети и соединениях между ними позволяет системе производить визуализацию работы компьютерной сети. Важная задача проверки узлов компьютерной сети на корректную работу решается в системе путем периодического отправления каждому узлу сети ICMP-запроса и ожидания от узла ответа. При получении отклика от конкретного узла в описывающее состояние узла поле базы данных (с названием «статус») записывается значение "1" (это означает нормальную работу узла). В случае, если заданный узел не отвечает (сервер не дожидается ответа на запрос в течение некоторого промежутка времени), в поле «статус» записывается "0", тем самым, сообщая системе о том, что узел перестал работать в штатном режиме. Система повторяет отправку запроса для проверки достижимости узлов сети каждые 5 секунд, таким образом, в базе данных постоянно хранится актуальная информация о состоянии узлов компьютерной сети. После добавления информации об элементах сети в базу данных и проверки работы всех узлов, система, используя эти данные, автоматически генерирует два XML-файла, в которых в упорядоченном виде содержатся данные об узлах и соединениях сети. Информация из этих файлов используются JavaScript-приложением в качестве входных данных для добавления на географическую карту Google Map всех элементов компьютерной сети (рис. 2). Элементы различных групп обозначаются на карте различными цветами и пиктограммами, при этом отображение нерабочих узлов отличается от отображения рабочих, даже если они принадлежат к одной и той же группе узлов (рис. 3). Таким образом система сигнализирует обслуживающему персоналу сети о сбоях, произошедших в ее работе. Для просмотра модели сети пользователю достаточно иметь браузер и выход в Интернет. Полученная 36

Труды конференции Телематика’2010

модель сети имеет определенный URL, поскольку, фактически, элементы сети «накладываются» на карту Google Map. На карте в удобном виде отображается структура компьютерной сети, причем по изображению конкретного элемента сети можно определить, работает он ли в нормальном режиме.

Рис. 2. Визуализация компьютерной сети RUNNet на геосистеме Google Maps

Рис. 3. Изображение функционирования узлов (работает корректно/не корректно) В итоге, реализованная и описанная выше система мониторинга создала полную и наглядную модель компьютерной сети, отображающую ее структуру и текущее состояние в режиме реального времени, то есть выполняющая поставленные задачи визуализации и проверки всех узлов на корректную работу. При этом система относительно легка в освоении, а большинство процессов в ней полностью автоматизированы. Кроме того, следует отметить, что система является легко масштабируемой и может быть использована для практически любой компьютерной сети. Разработанная система была обстоятельно протестирована и внедрена в практическую эксплуатацию для мониторинга (http://noc.runnet.ru/map) работы Федеральной университетской компьютерной сети России RUNNet (http://www.runnet.ru), поддержку и развитие которой осуществляет 37

Государственный научно-исследовательский институт информационных технологий и телекоммуникаций (ФГУ ГНИИ ИТТ «Информика»). В настоящее время система активно используется обслуживающим персоналом сети и, по мере необходимости, производится ее доработка и модернизация.

РАЗРАБОТКА АЛГОРИТМА И ПРОГРАММНЫХ СРЕДСТВ СИСТЕМЫ ПОСТРОЕНИЯ ТРЕХМЕРНОЙ ЦИФРОВОЙ КАРТЫ ВЫСОТ ПО НЕСКОЛЬКИМ ИЗОБРАЖЕНИЯМ А.А. Скляров, С.А. Скляров Технологический институт Южного федерального университета, г. Таганрог E-mail: [email protected] В настоящее время существует все больший спрос на системы построения трехмерной цифровой карты высот. Это связано с постоянным ростом развития беспилотных летательных аппаратов, зондов, сканирующих поверхность планеты. Информация, поступающая из таких летательных аппаратов, является двумерной, и её представление является менее удобной для человеческого восприятия, чем трехмерная модель, которая обладает большей информативностью. Так же системы построения трехмерных поверхностей широко используются для компьютерной графики или создания виртуальной модели мира. Качеству визуализации в подобных задачах уделяется особое внимание, поэтому геометрия поверхности должна быть достаточно точной. Системы построения трехмерной цифровой карты высот часто используются в комплексе со специализированными аппаратными средства. Примером таких аппаратных средств является лидар (транслитерация LIDAR англ. Light Identification, Detection and Ranging) – активный дальномер оптического диапазона, работающий по принципу радара: направленный луч источника излучения отражается от целей, возвращается к источнику и улавливается высокочувствительным приёмником (в случае лидара – светочувствительным полупроводниковым прибором); время отклика прямо пропорционально расстоянию до цели. Использование данного оборудования приводит к высокой стоимости системы построения трехмерной карты высот. Однако благодаря разработке новых алгоритмов обработки графической информации, можно выполнять построение трехмерных поверхностей с использованием не дорогостоящего фото или видео оборудования. В связи с постоянным ростом потребности в подобных системах, был разработан новый метод построения трехмерных карт высот. Суть метода состоит в том, чтобы построить трехмерную модель поверхности реального объекта, на основании двумерной информации моделируемой поверхности.

Рис. 1. Простейшая стереоскопическая система В теории алгоритм построения карты высот местности работает, когда две камеры, находящиеся в разных точках, регистрируют одну и ту же сцену. Пара изображений, получаемых при этом, называется стереопарой. Предположим частный случай, при котором одинаковые камеры расположены так, что их оптические оси параллельны, а прямая (базовая линия), проходящая через оптические центры, перпендикулярна оптическим осям. Предположим что длина отрезка (базы) расположенного на базовой линии и заключенного между оптическими центрами равна b. Выберем такую глобальную систему координат, начало которой O расположено на базовой линии посредине между оптическими центрами камер, ось OZ параллельна оптическим осям, а ось OX направлена вдоль базовой линии (рис. 1). Пусть начало координат в плоскостях изображений камер совпадают с главными точками (u0 = v0 = 0), а 38

Труды конференции Телематика’2010

единицы измерения координат в глобальной системе и в плоскостях изображения камер одинаковы (w = h = l). Выберем точку M с глобальными координатами (X, Y, Z). Координаты ее проекции в плоскости изображения первой камеры обозначим через (x’, y’), а в плоскости изображения второй камеры – через (x’’,y’’). Проекции одной и тоже точки в разных плоскостях называются сопряженными точками. Нетрудно доказать, что

x’ = f(X+b/2)/Z, x’’ = f(X-b/2)/Z, y’ = y’’ = fY/Z.

(1) (2) (3)

Z = fb/(x’ – x’’).

(4)

Откуда можно вычислить глубину:

Полученные соотношения позволяют вычислить полностью трехмерные координаты точки:

,

(5)

(6)

Разность d = x'-x" называется диспарантноcтъю. Ошибки в координатах проекций сильнее сказываются при малой диспарантности и, следовательно, расстояния до далеких объектов измеряются менее точно, чем до близких. С другой стороны, при фиксированной дальности диспарантность пропорциональна размеру базы, поэтому точность измерений повышается с увеличением базы [1]. На практике, в разрабатываемой системе существует одна камера, однако она регистрирует один и тот же участок земной поверхности подобно рассмотренному случаю, осуществляя движение вдоль оси OX. Для системы построения трехмерной поверхности был разработан алгоритм, состоящий из комплекса алгоритмов обработки изображений. Алгоритм построения трехмерной поверхности на основе нескольких изображений состоит из следующих этапов: 1. Получение кадра содержащего изображение моделируемой поверхности из устройств фотоили видеосъемки. 2. Получение следующего кадра из устройств фото- или видеосъемки. 3. Формирование стереопары. 4. Применение алгоритмов восстановления изображения к полученной стереопаре. 5. Бинаризация восстановленной стереопары. 6. Нахождение сопряженных точек. 7. Построение трехмерной карты высот. Раскроем содержание каждого этапа алгоритма построения трехмерной поверхности. 1-й и 2-й этапы алгоритма предназначены для получения стереопары моделируемой поверхности. Данный пункт предполагает, что система построения трехмерных поверхностей имеет возможность работать с устройствами видеонаблюдения. При определенных настройках разработанная система может работать в режиме реального времени. В данном режиме система успевает обрабатывать стереопару до прихода новой. Однако данный режим накладывает определенные ограничения к вычислительной мощности системы, так как для достижения заданной точности определения высоты необходимо произвести немало вычислительных операций в секунду. На 3-ем этапе алгоритма из полученных на этапе 1 и 2 изображений формируется стереопара необходимая для определения карты высот. Процесс формирования стереопары представляет собой создание определенной структуры содержащей в себе два изображения и их характеристики. Во время этого процесса проверяются характеристики изображений на сопоставимость, т.е. необходимо чтобы формат пикселя первого изображения соответствовал формату пикселя второго, это же касается и размеров изображений, они должны быть одинаковыми иначе данная стереопара изображений будет игнорирована. Сформированная стереопара состоит из изображений, полученных в результате фото- или видеосъемки при которых неизбежно появится аддитивный шум или несоответствие обшей яркости и контрастности. Для восстановления изображения от аддитивного шума на 4-ом этапе алгоритма применяется алгоритм медианной фильтрации. Алгоритм медианной фильтрации в данной работе служит для подавления лишней информации или шума в исходной двумерной информации. Изображения в процессе формирования их системами фото- или видеосъемки обычно подвергаются воздействию различных случайных помех или шумов. Фундаментальной проблемой в области обработки изображений является эффективное удаление шума при сохранении важных для последующего распознавания деталей изображения. Сложность решения данной задачи существенно зависит от характера шумов. В отличие от детерминированных искажений, которые описываются функциональными преобразованиями исходного изображения, для описания случайных воздействий используют модели аддитивного, импульсного и мультипликативного шумов [2]. 39

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

Образом точки при гауссовой фильтрации будет симметричное размытое пятно, с убыванием яркости от середины к краям, что гораздо ближе к реальному размытию от расфокусированных линз. Влияние пикселей друг на друга при гауссовой фильтрации обратно пропорционально квадрату расстояния между ними. Коэффициент пропорциональности, следовательно, и степень размытия, определяются параметром σ [2]. При осуществлении фото- или видеосъемки существует вероятность получения изображения с низкими яркостными характеристиками. Для повышения контрастности и яркости изображения на 4-ом этапе алгоритма применяется гистограммная эквализация. Результатом этого процесса будет увеличение динамического диапазона уровней яркости, что обычно означает большую контрастность выходного изображения. В общем случае гистограмма обрабатываемого изображения не будет равномерной в силу самой природы дискретных величин. Величины нормированной гистограммы являются приближениями вероятностей появления каждого уровня яркости на изображении. Преобразование эквализации имеет следующий вид:

при k = 1,…,L, где Sk – величина яркости выходного изображения, соответствующая значению яркости rk входного изображения, pr (rj), j = 1,…, L – гистограмма уровней яркости некоторого исходного изображения, rk – это k-ый уровень яркости из интервала [0, G], nk – число пикселей изображения, уровень яркости которых равен rk. n – общее число пикселей изображения. Значение G равно 255 для 32 полутонового изображения и 2 -1 для цветного изображения формата True Color [2]. После удаления шумов и выравнивания яркостных характеристик стереопары, её необходимо преобразовать в двоичный вид для упрощения процесса распознавания при нахождении сопряженных точек моделируемой поверхности. Данный процесс называется бинаризацией изображения и для его осуществления на 5-ом этапе алгоритма построения трехмерной модели поверхности используются линейные фильтры, задаваемые дискретными аппроксимациями дифференциальных операторов (по методу конечных разностей), в комплексе с пороговой фильтрацией. Простейшим дифференциальным оператором является взятие производной по x-координате

.

Данный оператор определен для непрерывных функций. Существует множество способов определить аналогичный оператор для дискретных изображений при помощи линейного фильтра. В частности, распространенными вариантами являются фильтры Прюита (Prewitt) и Собеля (Sobel). В результате применения разностных операторов получается, как правило, изображение со средним значением пикселя близким к нулю (сумма элементов ядра равна нулю). Вертикальным перепадам (границам) исходного изображения соответствуют пиксели с большими по модулю значениями на результирующем изображении. Поэтому разностные фильтры называют также фильтрами, находящими границы [2]. Для представления границ в бинарном виде после применения разностных фильтров к стереопаре, применяется алгоритм пороговой фильтрации. Результатом пороговой фильтрации служит бинарное изображение, определяемое следующим образом:

(9) 40

Труды конференции Телематика’2010

где A(x,y) – значение интенсивности пикселя в точке с координатами (x,y) исходного изображения, B(x,y) - значение интенсивности пикселя в точке с координатами (x,y) преобразованного в бинарный вид изображения, – порог фильтрации. После применения всех преобразований получается стереопара с бинарным представлением границ изображений. Для дальнейшего построения трехмерной карты высот необходимо найти местоположение сопряженных точек. Очевидно, что при решении этой задачи речь идет об отождествлении не отдельных точек, а фрагментов изображений, лежащих в окрестностях этих точек. Для отождествления фрагментов изображений, образующих стереопару, применяется алгоритм, основанный на вычислении корреляции между признаками фрагментов изображений [2]. Будем считать, что изображение эталонного фрагмента (области вокруг точки находящейся на первом снимке A и представляемого матрицей U0 размером nxn), сравнивается с изображениями фрагментов второго снимка B в «зоне поиска» Ω размером LxL, L = n + m . Перекрытие между 2 2 фрагментами определяется шагом h дискретной решетки hZ (в плоскости Р ), на которой заданы наблюдаемые переменные {u0(х), х = (х,у)} на А или {u(х)} на В. В процессе скользящего поиска (когда каждый очередной фрагмент получается из предыдущего простым сдвигом на один шаг) вычисляется «функция сходства» между изображением эталонного фрагмента {u0(х), ГА} и изображениями текущих (контролируемых) фрагментов {u(х),

ГВ}. Здесь требуется найти функцию сходства, которая

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

(10) где а и b – параметры контраста и средней освещенности; k, l – параметры относительного сдвига образца и его аналога на контролируемом снимке; – шум;

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

В качестве меры различия в точке (k,l) будем брать среднеквадратическую ошибку

которая минимизируется перебором всех допускаемых сдвигов эталона по заданной области контролируемого снимка. Считается, что в точке экстремума реализуется сходство, если где λ – некоторый установленный порог. Из требования минимума ошибки

находим

оценку а, подставляем ее в формулу (13) и приходим к выражению

Первый член выражения 14) – «энергия» эталонного сигнала – является величиной постоянной, не зависящей от параметров сдвига (к,l). Поэтому точка экстремума не изменится, если мы будем нормировать среднеквадратическую ошибку к энергии эталона 41

и вместо минимума нормированной среднеквадратической ошибки будем искать максимум коэффициента корреляции текущего фрагмента с эталоном

Соблюдение условий достоверности обнаружения также приводит к необходимости устанавливать порог для величины взаимной корреляции max : если max , то с заданной вероятностью гарантируется действительное сходство найденной пары фрагментов. Величина порога определяется функцией распределения коэффициента корреляции (при случайных выборках) и задаваемой доверительной вероятностью принятия решения о действительном сходстве фрагментов [1]. После нахождения тождественных областей вокруг сопряженных точек можно вычислить координаты трехмерной проекции сопряженных точек по формулам (4) (5) (6). На 7-ом этапе алгоритма построения трехмерной карты высот происходит вычисление глубины трехмерных проекций сопряженных точек и сохранение результат в виде карты высот. Так как полученные высоты поверхности являются относительными, то для определения точных значений необходимо иметь информацию о начальной высоте объекта осуществляющего фото- или видеосъемку. Существуют ограничения по применению алгоритма построения трехмерной карты высот, в частности высота объекта осуществляющего фото- или видеосъемку должна иметь малый коэффициент изменения на протяжении всего времени работы алгоритма. Также частота кадров должна прямо пропорционально зависеть от скорости передвижения объекта осуществляющего фото- или видеосъемку. Следует отметить, что точность алгоритма построения трехмерной карты высот зависит от качества изображения полученного из устройства фото- или видеонаблюдения. На основе алгоритма построения трехмерной модели поверхности было разработано программное обеспечение, осуществляющее построение трехмерной карты высот по нескольким изображениям рассматриваемой местности. Пользователь разработанной системы имеет следующие возможности: 1. Выбирать последовательность снимков из устройства хранения информации или устанавливать режим работы системы в реальном времени. 2. Изменять параметры алгоритма для вариации степени детализации трехмерной модели поверхности. 3. Осуществлять предварительный просмотр построенной трехмерной модели: изменение масштаба; изменение угла обзора. 4. Сохранять построенную трехмерную модель рассматриваемой поверхности. Разработанная система отличается от своих аналогов, работающих на основе применения специализированных аппаратных средств, низкой себестоимостью, тем самым имеет практическую значимость для предприятий, работающих в сфере геоинформационных систем (ГИС). Литература 1. 2.

И.С. Грузман, B.C. Киричук. Цифровая обработка изображений в информационных системах, НГТУ, Новосибирск, 2002. Р. Гонсалес и Р. Вудс Цифровая обработка изображений, Техносфера, Москва, 2006.

СИСТЕМА ОЦЕНКИ И ПРОГНОЗИРОВАНИЯ УРОВНЯ КАЧЕСТВА ОБСЛУЖИВАНИЯ В IP-СЕТЯХ С ПРИМЕНЕНИЕМ АППАРАТА ТЕОРИИ СЛОЖНОСТИ В.Е. Подольский, С.С. Толстых, М.М. Дружинин Тамбовский государственный технический университет E-mail: [email protected], [email protected], [email protected] Современные компьютерные сети стремительно развиваются, на их основе формируются современные системы цифрового телевидения, сетевые информационные системы большой размерности, распределенные вычисления. Совокупность поставщиков и потребителей информации представляет собой единое информационное пространство. Перед разработчиками новых компьютерных сетей и перед специалистами, занимающимися вопросами модернизации уже существующих систем, возникают задачи оценки и прогнозирования уровня качества обслуживания. В компьютерных сетях большой размерности, функционирующих на 42

Труды конференции Телематика’2010

уровне крупных городов и регионов, принятие решений по реконструкции существующих телекоммуникаций и перераспределению потоков информации усложняется тем, что общее число параметров, которые можно, в принципе, принять к рассмотрению, чрезвычайно велико. Это, прежде всего, данные о трафике в многочисленных узлах сети. Однако, качество обслуживания клиентов сети нельзя оценить лишь объемом трафика. Необходимо принимать во внимание такие факторы, как пропускная способность каналов, задержки в прохождении пакетов, количество пакетов, переданных с недопустимыми задержками и др. Для сети большой размерности суммарный объем данных, которые необходимо переработать и принять решения, исчисляется гигабайтами. С учетом того, что число системных администраторов весьма ограничено, мощности компьютеров в узлах сети отнюдь не безграничны, большая часть статистики работы сети оказывается невостребованной. Значительную роль в развитии современных телекоммуникационных услуг играет все возрастающая конкуренция поставщиков. Немалую роль в успехе работы провайдеров играет человеческий фактор, мнение пользователей, у которых зачастую есть выбор, к какому именно провайдеру следует подключиться. В этой связи вопросы качества обслуживания становятся первостепенными. С позиции конечного пользователя, выбор провайдера следует производить по двум кардинальным признакам: • Безотказность работы сети – определяется временем простоев, связанных с ремонтом и устранением неисправностей, в отношении к тому или иному стандартному промежутку, например, месяцу. • Соответствие реального и обещанного быстродействия канала клиент-сервер по совокупности тех услуг, на получение которых пользователь рассчитывал, заключая контракт, в том числе и на услуги в сфере мультимедиа. Нельзя не отметить, что на политику развития компьютерных сетей, проводимую поставщиками информационных услуг, первостепенное влияние оказывает динамика прибыли. Типичная политика многих провайдеров подразумевает расширение ареала пользователей, прокладку новых коммуникаций, увеличение быстродействия каналов. Однако, решить задачу прогнозирования в сфере предоставления услуг телекоммуникаций порой не удается без тщательного анализа существующего положения и имитационного моделирования развития ситуации в будущем. И то, и другое невозможно без комплексного моделирования работы компьютерной сети большой размерности (КСБС). При оценке состояния компьютерной сети можно выделить две основные цели и модели анализа, соответствующие им: • Статическая модель – получение численных значений, показывающих соотношение различных проектных решений с последующим выбором одного из них. • Динамическая модель – оценка действующей сети на предмет её работоспособности, отказоустойчивости, стабильности и других показателей качества для выявления проблемных участков и для прогнозирования мероприятий по реконструкции. Вполне естественным представляется желание найти некоторый обобщенный показатель, характеризующий состояние компьютерной сети. При этом важно определить цель, преследуемую при формировании критерия состояния сети. В условиях, когда маркетинговый анализ показывает, что предприятие-провайдер успешно функционирует на рынке телекоммуникационных услуг, важно знать насколько стабильно это положение. Таким образом, в качестве цели формирования критерия выдвигается стабильность компьютерной сети как сетевой информационной системы. Главное отличие сетевых информационных систем, основанных на компьютерных взаимодействиях в сетях общего пользования, от распределенных информационных систем – многомерность целевого пространства, невозможность определить диаметр целевой сферы. В таких случаях традиционные схемотехнические подходы к оценке состояния технических систем, подразумевающие оценку диаметра целевой сферы, к КСБС неприменимы. Выбор методической основы для формирования критерия состояния компьютерной сети ограничен альтернативой: либо использовать статистику работы сети для нахождения информационной энтропии, либо оценивать структурно-параметрическую сложность. В первом случае необходимо привлекать максимальное количество данных, при этом число состояний, чьи вероятностные характеристики следует учитывать в формулах информационной энтропии, в КСБС нереально велико. Под стабильностью технической системы понимается способность системы удерживать структуру в неизменном виде. В КСБС можно рассматривать отдельно два вида структур: 1) структура информационных потоков и 2) структура информационных каналов. Вполне очевидно, что первый вид структур слишком изменчив во времени, в процессе работы любой современной сети огромную работу проводят маршрутизаторы, работающие в автоматическом режиме. Учесть все возможные перенаправления потоков и их раздачу в узлах сети нереально: большая размерность сети, ее нетривиальная топология вступают в противодействие с детерминизмом орграфа. Именно это явилось причиной выбора в качестве основы для построения орграфа КСБС структуру информационных каналов. Ориентация дуг отражает асимметричность трафика. Задача взвешивания элементов орграфа сводится к определению набора параметров, характеризующих элементы, с последующей консолидацией в значение веса дуги или вершины. Для оценки отдельных частей сети передачи данных (веса структурных элементов орграфа) могут использоваться различные подходы. Некоторые оценки справедливы для сетей любого масштаба, другие характерны именно для КСБС. В сети можно выделить две сущности разного свойства: • Каналы передачи данных, им соответствуют дуги орграфа; 43

• Узлы передачи данных (маршрутизаторы, коммутаторы), им соответствуют вершины орграфа. Параметры, применяемые для их оценки, можно разделить на категории, в зависимости от их свойств: • Постоянные – значение параметра не меняется с течением времени (либо его изменением на рассматриваемом периоде можно пренебречь). • Периодические – параметр меняется, но подчиняется известным, как правило, колебательным законам. Для сети передачи данных различаются колебания дневные, недельные и месячные. Оценка периодических параметров подразумевает обработку статистики по всем трём указанным периодам. • Непериодические – параметр меняется во времени, но не подчиняется периодическим законам (монотонное поведение). • Случайные – не поддаются систематической оценке, появляющиеся из-за случайных изменений условий использования трафика отдельными потребителями. Большинство реальных параметров сети имеют все эти составляющие в какой-либо пропорции, но, при стабильной работе сети, одна из них является преобладающей. Каналы передачи данных можно разделить на 3 уровня: • Каналы к оконечным потребителям (последняя миля). Максимальная скорость от 10 до 100 Мбит/с, возможна скорость 1 Гбит/с при подключении серверов. • Магистральные каналы между пользователем и ядром сети. Скорости магистральных каналов составляют, как правило, 1 Гбит/c. Суммарная загрузка канала состоит из суммы потребления трафика всеми пользователями, подключенными с помощью данного канала к ядру сети, за вычетом суммы трафика между пользователями. Для каналов характерно двойное резервирование: маршрут к точке доступа может проходить через два канала, и, при отказе одного из них, может включаться вспомогательный канал. • Каналы ядра сети. Скорость 1 Гбит/c. Для каналов данного типа в большей степени характерно резервирование, чем для магистральных каналов. Все узлы, входящие в ядро сети, имеют каналы для связи со всеми остальными узлами сети. В результате проведенного анализа были выявлены параметры (табл. 1), характеризующие компьютерную сеть большой размерности (КСБС). Таблица 1. Параметры элементов КСБС Единица измерения

Тип

бит/с

постоянный

Задержки в канале, свойственные конкретике передачи TCP пакета. В качестве значения параметра принимается усреднённая по серии замеров величина.

мс

постоянный

Приоритетность канала (эмпирическая важность канала, метрика канала, 0 – наименее важный канал), степень важности данного канала.

–

постоянный

Надёжность канала (его отказоустойчивость)

%

постоянный

Процент полной загрузки – процент времени, в течение которое канал имеет загруженность сверх установленного порога (80%). Измеряется для определённого промежутка времени.

%

периодический

Загруженность канала (процент от пропускной способности канала).

%

периодический

руб.

постоянный

%

периодический

Суммарный трафик узла.

байт

периодический

Скорость обработки трафика узлом.

бит/c

постоянный

Стоимость узла (за период эксплуатации).

руб.

постоянный

Описание Параметры каналов Пропускная способность канала.

Стоимость канала (сколько средств необходимо потратить в единицу времени на поддержание канала в рабочем состоянии). Параметры узлов Загруженность процессорного блока.

В задачах имитационного моделирования периодичностью величин можно пренебречь и использовать их средние значения (возможно также использование таких статистических характеристик, как, например, дисперсия). Стоимость узла или канала включает в себя единовременную стоимость покупки и стоимость владения (арендные платы, стоимость потребляемой электроэнергии и стоимость обслуживания, в том числе зарплату работников). Надёжность канала оценивается по статистическим данным. Приоритетность канала устанавливается аналитиком и назначается, исходя из конкретных задач, возложенных на данный канал передачи данных. Так, например, тот или иной канал может 44

Труды конференции Телематика’2010

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

Вес дуги Vд = k1/S + k2d+ k3P+ k4Mд,, Вес вершины Vв = k5T + k6C+ k7Mв, где Mд – стоимость канала;

Mв – стоимость узла; S – пропускная способность канала; d – задержки P – приоритетность канала; T – трафика узла; С – загруженность процессорного блока узла. Весовые коэффициенты k1-7 зависят от решаемых задач. Для каналов они зависят от типа канала: для

в канале;

отдельных каналов возможно преобладание задач скорости или надёжности над ценой самого канала. В процессе структуризации КСБС необходимо учитывать взаимодействия каналов связи и узлов, которые могут вносить изменения в структуру распределения трафика по сети, причем в разные периоды функционирования эти взаимодействия могут меняться. В данном случае речь идет о принудительных мерах маршрутизации, например, разделение трафика между несколькими маршрутами. Необходимо учитывать также процедуры «сужения канала», к примеру, со 1 Гбит до 100 Мбит, при котором часть пакетов будет отбрасываться. В период эксплуатации ведется сбор статистики с узлов связи. В настоящий момент подавляющее большинство устройств сети (коммутаторы, маршрутизаторы, персональные компьютеры) позволяют отдавать различные параметры их работы через протокол SNMP, либо через соединение с ними по протоколам telnet, SSH. Для получения статистики КСБС создано программное обеспечение, осуществляющее сбора всех параметров из табл. 1. Параметры записываются в реляционную базу данных для последующего анализа. Анализ статистики проводится с использованием аппарата теории сложности. При оценке эффекта модернизации строится орграф сети до проведения работы и предполагаемый орграф после их проведения. Для новых каналов связи устанавливаются усреднённые параметры, которые специалист может оценить по параметрам других элементов сети. Для всех имеющихся вариантов вычисляют величину структурно-параметрической сложности системы, и выбирается тот вариант, который имеет наименьшее значение оценки сложности [1]. Для оценки качества обслуживания клиентов КСБС проводится статистический анализ структурнопараметрической сложности как случайной величины. Мерой качества обслуживания является дисперсия оценок. Чем ниже величина дисперсии, тем выше качество обслуживания. Стабильность работы КСБС определяется положительными отклонениями оценки структурно-параметрической сложности от среднего значения. Чем больше сумма отклонений за некоторый период функционирования КСБС, тем стабильность системы хуже. Периодически решается задача прогнозной маршрутизации: выбирается тот или иной канал, называемый кардинальным (наиболее влиятелен), и решается задача оптимального управления, результатом решения которой является тренд управления пропускной способности канала. Минимальное значение функционала отклонений от среднего значения структурно-параметрической сложности соответствует наиболее стабильному состоянию КСБС на периоде прогнозирования. Разработанная система оценки и прогнозирования уровня качества КСБС на основе аппарата теории сложности является реализацией комплексного подхода к оценке состояния IP-сетей, позволяет заблаговременно предотвращать возможные негативные последствия роста размерности и всплесков активности потребления трафика. Литература 1.

2.

Подольский В.Е., Толстых С.С. Повышение эффективности региональных образовательных компьютерных сетей с использованием элементов структурного анализа и теории сложности. М.: Машиностроение, 2006. – 174 с. Особенности математического моделирования современных компьютерных сетей в образовательной сфере / А.Н. Тихонов, С.В. Мищенко, В.Е. Подольский, С.С. Толстых // Телематика’2003, СПб., 2004. Т.1. С. 78–79.

45

ИЗМЕРЕНИЯ СЕТЕВОЙ ПОЛОСЫ ПРОПУСКАНИЯ ПО ДАННЫМ О ЗАДЕРЖКЕ ПАКЕТОВ Т.Г. Султанов1, А.М. Сухов1, Д.Ю. Полукаров2 1) Самарский государственный аэрокосмический университет, 2) Поволжский государственный университет телекоммуникаций и информатики, г. Самара E-mail: [email protected] Введение Различные приложения реального времени в Интернет, прежде всего, передача звука и изображения, становятся все более и более популярны и для их качественной работы приложениям требуются высокоскоростные сети. Среди факторов, определяющих качество предоставляемого мультимедийного сервиса: качество оборудования (кодек и видеосервер) и доступная пропускная способность канала. Провайдеры должны обеспечить требуемую пропускную способность для голосовых и видео приложений для гарантированного представления подобных сервисов в глобальной сети. В данной работе сетевой маршрут определяется как последовательность соединений (hop), по которым проходят пакеты от отправителя к получателю. Есть различные определения для метрик пропускной способности, но здесь мы будем следовать подходам, принятым в работах [5, 9, 10]. Две метрики, обычно связываемые с маршрутом, это доступная (available bandwidth) и полная (capacity) пропускная способность. Полная пропускная способность (C – capacity) – это максимальная полоса пропускания уровня IP, которую может предоставить данный маршрут потоку при отсутствии конкурирующего потока. С другой стороны, доступная пропускная способность Bav – это максимальная пропускная способность уровня IP, которую данный маршрут может предоставить потоку в конкретной ситуации загруженности маршрута конкурирующим трафиком. Соединение с минимальной пропускной способностью определяет полную пропускную способность всего маршрута, также и соединение с минимальной свободной от конкурирующего трафика пропускной способностью – определяет доступную полосу пропускания всего маршрута. Измерение доступной пропускной способности необходимо не только для определения состояния сети, но и для предоставления информации сетевым приложениям, необходимой для контроля исходящего сетевого трафика и правильного разделения пропускной способности сети. Для того чтобы составить правильное представление о глобальной сети (для мониторинга и предотвращения узких мест) и разработки новых дополнений стандартов, следует использовать современную измерительную инфраструктуру. В данной работе описывается и используется широко распространенная система измерения RIPE Test Box [7]. Однако данная система не измеряет доступную пропускную способность. Но она записывает данные, характеризующие ключевые сетевые параметры, такие как задержка, вариация задержки (джиттер), путь маршрутизации (маршрут) и т.п. Эти данные позволяют изучить взаимозависимости между доступной пропускной способностью и основными сетевыми параметрами. Наша цель – оценить доступную пропускную способность по значениям задержки пакетов. 1. Модель и область её применимости Простейшее выражение для оценки доступной пропускной способности, описывающее соотношение между временем обработки пакета в сети (задержкой) и размером пакета, следует из формулы Литтла [13]:

Bav =

W , D

(1)

где Bav – доступная пропускная способность [бит/с], W – размер передаваемого пакета [байт], а D – время передачи данного пакета [с] (One Way Delay). Данная формула подходит для расчета доступной пропускной способности между двумя точками сети при отсутствии маршрутизирующих устройств. В реальных условиях величина задержки пакета зависит от таких факторов, как время распространения сигнала, задержка передачи, время обработки пакета маршрутизатором и др. В работе [1] было показано, что в общем виде преобразование Литтла с оценкой доступной пропускной способности может быть записано как:

Bav =

W , D − D fixed

(2)

где Dfixed – минимальная задержка пакета [с] размера W. Разность между задержками D и Dfixed есть величина переменной части задержки dvar. В работе [3] было показано, что эта величина распределена экспоненциально. В 1999 году Downey [6] обнаружил линейную зависимость двухсторонней задержки пакетов в сети (Round Trip Time) от их размера. В 2004 уточняющие эксперименты групп во главе Choi [2] и Hohn [12] показали, что минимальная задержка Dfixed(W) для пакета размера W является аффинной функцией его размера: 46

Труды конференции Телематика’2010 h

h

i =1

i =1

D fixed (W ) = W ⋅ ∑ 1 / C i + ∑ δ i ,

(3)

где Ci – пропускная способность канала на соответствующем участке маршрута [бит/с], δi – физическая задержка прохождения пакета [с]. Для подтверждения этого предположения экспериментально находилась минимальная задержка пакетов одинакового размера для трех разных маршрутов и строилась функция в зависимости задержки от размера пакета W. Для того чтобы устранить минимальную задержку Dfixed(W) из уравнения (2) было предложено тестировать сеть пакетами разного размера [1], так чтобы размер пакета различался на максимально возможную величину. Тогда уравнение (2) может быть преобразовано к виду, пригодному для измерения доступной пропускной способности:

Bav =

W 2 − W1 D2 − D1

(4)

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

η=

∆B 2∆D = , B D2 − D1

(5)

где η – относительная погрешность измерения доступной пропускной способности [%], ∆B – абсолютная погрешность измерения доступной пропускной способности [бит/с], а ∆D – точность метода измерения задержки пакета [с]. Из этого выражения легко найти верхнюю границу

B =

B

W2 −W1 η 2∆D

для измеряемой пропускной способности:

(6)

Таким образом, с помощью системы RIPE Test Box, позволяющей находить задержку с точностью в 2 микросекунды ∆D=2·10-6 с, можно измерять пропускную способность до верхней границы B = 300 Мбит/с с погрешностью η = 10%. А с помощью стандартной утилиты ping, при относительной -3 погрешности η = 25% и точности в 1 миллисекунду ∆D = 10 с можно измерять пропускную способность каналов до 1,5 Мбит/с. 2. Экспериментальное сравнение различных методов измерений доступной пропускной способности В настоящем разделе статьи будет проведено сравнение различных методов измерений доступной пропускной способности и результатов, полученных при их помощи. Эксперимент проводился в три этапа, первый из них – это прецизионное тестирование большим количеством пакетов разного размера с помощью измерительной системы RIPE Test Box. Количество измерительных узлов этой системы достигает 80, эти узлы покрывают основные мировые интернетцентры, достигая наибольшей плотности в Европе. Погрешность измерений задержки пакетов составляет 2-12 мкс [14]. Три точки RIPE Test Box были установлены в Москве, Самаре и Ростове-наДону в течение 2006-2008 гг. по гранту РФФИ 06-07-89074. Нами для последующего анализа были собраны несколько наборов данных, содержащих до 3000 измерений на различных направлениях, прежде всего, на участке Самара – Амстердам (tt01.ripe.net – tt143.ripe.net). На основании этих данных нами рассчитана доступная пропускная способность и исследована зависимость ошибки измерений от количества проведенных измерений (рис. 2). На втором этапе было проведено сравнение данных, полученных нашим методом, с результатами уже существующих методик измерения. В качестве инструмента, реализующего альтернативный метод измерений, был выбран программный продукт pathload [10]. Данный программный продукт считается одним из лучших инструментов для оценки доступной пропускной способности канала. Pathload использует технологию Самозагружающихся Периодических Потоков (Self-Loading Periodic Streams, SLoPS). В его основе лежит клиент-серверная архитектура, которая является его недостатком, поскольку требуется установить утилиту на оба хоста. Достоинством является тот факт, что для запуска pathload не требуется привилегий суперпользователя, так как он посылает только UDP-пакеты. 47

На третьем этапе проводится сравнение данных, полученных на втором этапе, с данными, снятыми напрямую с маршрутизатора СГАУ, который обслуживает самый узкий участок сети.

Рис. 1. Схема проведения эксперимента Этапы эксперимента проводились между точками tt143.ripe.net (Самара, СГАУ) и tt146.ripe.net (FREENet, ИОХ РАН, Москва). Таким образом, эксперимент состоит из трех частей: • измерение доступной пропускной способности методом тестирования парами пакетов разных размеров с помощью измерительной системы RIPE Test Box (размер пакетов 100 и 1100 байт); • измерения доступной пропускной способности с помощью утилиты pathload • измерение доступной пропускной способности на маршрутизаторе СГАУ, который обслуживает самый узкий участок (рис. 1). Стоит отметить, что все три проверки должны проводиться одновременно с целью обеспечения максимальной достоверности получаемой статистики. Структура измерительной системы RIPE Test Box отвечает всем требованиям, предъявляемым нашим методом – она позволяет менять размер тестирующего пакета и находить с высокой точностью задержку. По умолчанию тестирование ведётся пакетами размером 100 байт, но существует специальные настройки, с помощью которых можно добавить тестирование любой точки RIPE Test Box пакетами размером до 1500 байт с требуемой частотой. В нашем случае разумно добавить пакеты размером 1100 байт. Следует отметить, что тестирование указанными пакетами начинается только через сутки после отправки специальной заявки. Чтобы получить доступ к результатам тестирования необходимо обратиться по удаленному доступу (telnet) к RIPE Test Box по порту 9142. Полученные данные будут содержать сведения об искомой задержке пакетов разных размеров. Отметим, что исследуемая модель предполагает оперирование со средней величиной W2 − W1 , поэтому необходимо усреднить несколько значений, идущих последовательно. В рассматриваемом эксперименте

усредненная

разность

Dav (1100) − Dav (100)

составила

0,000815

секунды

в

направлении tt143->tt146. Тогда доступная пропускная способность может быть рассчитана как:

B av ( tt 143 − > tt 146 ) =

8 × 1000 0 . 000815

= 9 . 8 Mbps

Усредненная разность в направлении tt146->tt143 составила 0,001869 с. Тогда доступная пропускная способность составит:

B av ( tt 146 − > tt 143 ) =

8 × 1000 0 . 001869

= 4 . 28 Mbps

Работа программного продукта pathload отличалась попеременными сбоями, несмотря на то, что были открыты все необходимые порты. В направлении измерения tt146->tt143 программа вообще не выдавала результат, простаивая и попусту загружая канал цепочками пакетов. Результаты, которые выдавала программа, отличались большим разбросом значений, явно выходящих за рамки пропускной способности внешнего канала СГАУ. Были сделаны попытки сравнить результаты с такими программными продуктами, как pathChirp и IGI, но они не увенчались успехом. Программы выдавали ошибки и отказывались измерять доступную пропускную способность. Поэтому было принято решение сравнить результаты, полученные различными методами, с данными, полученными напрямую с маршрутизатора. С помощь утилиты traceroute было определено 48

Труды конференции Телематика’2010

«узкое место» маршрута пакетов между СГАУ и ИОХ РАН, им оказался внешний маршрутизатор СГАУ, пропускная способность канала на котором была ограничена 30 Мбит/с. При помощи SNMP-агента была снята статистика с граничного маршрутизатора СГАУ. Все данные приведены в таблице 1 с указанием времени проведения эксперимента. Таблица 1. Сравнительный анализ результатов измерений № пп

Время проведения эксперимента

Направление измерений

1 2 3 4 5 6

13.01.2010 13.01.2010 23.01.2010 23.01.2010 06.02.2010 06.02.2010

tt143->tt146 tt146->tt143 tt143->tt146 tt146->tt143 tt143->tt146 tt146->tt143

Доступная пропускная способность канала по данным RIPE Test Box 10.0±2.2 Mbps 4.4±1.2 Mbps 20.3±5.1 Mbps 9.3±2.7 Mbps 9.2±1.4 Mbps 3.5±1.2 Mbps

Доступная пропускная способность канала по данным pathload

Данные с маршрутизатора

21.9±14.2 Mbps

12.1±2.5 Mbps 7.8±3.8 Mbps 18.7±1.1 Mbps 11.3±2.6 Mbps 12.0±2.0 Mbps 4.5±2.0 Mbps

41.2±14.0 Mbps 67±14 Mbps

Из таблицы 1 видно, что результаты, полученные нашим методом, и данные, собранные утилитой MRTG с маршрутизатора, хорошо согласуются, в то время как результаты pathload сильно отличаются. Работы по исследованию типа переменной части задержки [3] дают ответ на вопрос, почему так происходит. Разброс результатов измерений объясняется наличием переменной части задержки dvar. Это и является причиной фантастических результатов pathload в 90 Мбит/с на канале с максимальной пропускной способностью в 30 Мбит/с. 3. Условие устойчивой работы утилит, измеряющих доступную пропускную способность Чтобы понять, как влияет переменная часть на результаты измерений, обратимся к следующему эксперименту. Между точками RIPE Test Box tt01.ripe.net (Амстердам, Голландия) и tt143.ripe.net (СГАУ, Самара) был проведён ряд измерений и получено около 3000 значений задержек пакетов размером 100 и 1024 байта в обоих направлениях. С помощью представленного метода были рассчитаны величины доступной пропускной способности канала, для случаев, когда усреднение ведется по 20, 50 и 100 парам значений задержек пакетов. На рис. 2 представлен график, отображающий изменения рассчитанной пропускной способности в зависимости от выбранного для усреднения количества пар пакетов.

Рис. 2. Зависимость доступной пропускной способности от количества измерений Как видно из графика, биения рассчитанной пропускной способности являются критичными при 20 значениях задержек, при 50 они менее заметны, а при 100 значениях линия графика практически выравнивается. Прослеживается явная зависимость между количеством измерений и вариацией рассчитанной пропускной способности. Наличие биений обусловлено переменной частью задержки. Отметим, что её роль снижается при увеличении количества измерений. На основании данных, полученных в ходе эксперимента между точками tt01 и tt143, нами были вычислены среднеквадратические отклонения (СКО) σn(B) для доступной пропускной способности для пакетов разных размеров (табл. 2).

49

Таблица 2. Зависимость СКО от числа измерений Число измерений, n Среднеквадратическое отклонение, σn(B) (Мбит/с)

5

10

20

30

40

50

70

100

200

300

22.2

14.9

10.2

8.3

7.3

6.7

5.7

4.9

2.9

2.3

Среднее значение доступной пропускной способности сети, Bav (Мбит/с)

13.1

Из таблицы 2 очевидно, что необходимо брать как минимум 50 измерений (разность для 50-ти пар пакетов), в этом случае рассчитанное значение пропускной способности в 2 раза превышает СКО, то есть:

B ≥ 2 ⋅ σ n ( B) .

Более аккуратный результат можно получить при помощи обобщенной генерирующей функции для описания задержек пакетов. В работе [3] было установлено, что распределение задержки подчиняется экспоненциальному закону, а для длительности задержки можно использовать следующую генерирующую функцию:

D = Dmin + W / B − (1 / λ ) ln(1 − F ( D,W )) , где

λ = 1 /( Dav − Dmin ) ,

(7)

а функция F(W,D) эмулируется стандартным генератором случайных

чисел на интервале [0; 1). Знание формы генерирующей функции дает возможность рассчитать табличные значения функции

η nT из уравнения (5). Для этого при помощи генерирующей функции (7) рассчитаем значения СКО σ nT ( D2 − D1 ) для усредненной разности от задержек пакетов разных размеров [мс], приняв

λT = 1000

с-1.

T -1 Таблица 3. Эмуляция зависимости СКО от количества измерений (λ = 1000 с )

Число измерений, n

5

10

20

30

50

100

200

Среднеквадратическое отклонение, (мc)

0.661

0.489

0.354

0.284

0.195

0.111

0.075

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

η nT .

∆W T = W2 − W1 = 1000 байт, BT = 10 Мбит/с, что

D2T − D1T = 8·10-4 c.

Таблица 4. Зависимость погрешности от количества измерений Число измерений, n Погрешность измерений,

(%)

5

10

20

30

50

100

200

82.6

61.1

44.2

35.5

24.4

13.9

9.4

В ходе реального эксперимента измеряемые значения λ , D2 − D1 или B принимают произвольные значения, но поправочные коэффициенты позволяют легко рассчитать требуемое количество измерений для оценки экспериментальной погрешности измерений из табличных значений: exp

exp

ηnT = k ( D2 − D1 ) ⋅ k (λ ) ⋅ η exp , где

k (λ ) = λexp / λT

а

η exp

сравним полученные значения с

требующихся для достижения заданной погрешности. 50

exp

(8)

k ( D2 − D1 ) = ( D2exp − D1exp ) /( D2T − D1T ) .

k ( D2 − D1 ) , k (λ ) и требуемую погрешность T табличными η n и найдем число измерений n,

Подставляя в уравнение (8) значения коэффициентов измерений

exp

Труды конференции Телематика’2010

Выводы В данной работе проведена экспериментальная проверка нового метода с использованием измерительной инфраструктуры RIPE Test Box. Это позволило обеспечить высокую точность результатов эксперимента. Было произведено сравнение данных, полученных описанным в работе методом, с результатами уже существующих технологий измерений доступной пропускной способности. В качестве сравнительного инструмента была выбрана утилита pathload. В результате проверки выяснилось, что разработанный метод обладает преимуществами по сравнению с другими технологиями измерения, так как последние в достаточной мере не учитывают влияние переменной части задержки. Показано, что для точного измерения доступной пропускной способности канала, необходимо нивелировать влияние dvar, путем увеличения количества проводимых измерений. Были найдены границы применимости модели на основе точности измерений, проведено компьютерное симулирование и найдена связь между ошибкой измерения доступной пропускной способности и количеством измерений. Литература 1.

2. 3. 4.

5.

6. 7. 8. 9. 10. 11.

12. 13. 14.

Платонов А.П., Сидельников Д.И., Стрижов М.В., Сухов А.М., Измерительная инфpастpуктуpа для изучения качества соединений в российском сегменте Интернет, Телекоммуникации, 2009, № 1, С. 11-16. Choi, B.-Y., Moon, S., Zhang, Z.-L., Papagiannaki, K. and Diot, C.: Analysis of Point-To-Point Packet Delay In an Operational Network. In: Infocom 2004, Hong Kong, pp. 1797-1807 (2004). A.M. Sukhov, N Kuznetsova, What type of distribution for packet delay in a global network should be used in the control theory? 2009; arXiv: 0907.4468. Padhye, J., Firoiu, V., Towsley, D., Kurose, J.: Modeling TCP Throughput: A Simple Model and its Empirical Validation. In: Proc. SIGCOMM Symp. Communications Architectures and Protocols, pp. 304-314 (1998). Dovrolis C., Ramanathan P., and Moore D., Packet-Dispersion Techniques and a CapacityEstimation Methodology, IEEE/ACM Transactions on Networking, v.12, n. 6, December 2004, p. 963-977. Downey A.B., Using Pathchar to estimate internet link characteristics, in Proc. ACM SICCOMM, Sept. 1999, pp. 222-223. Ripe Test Box, http://ripe.net/projects/ttm/. Jacobson, V. Congestion avoidance and control. In Proceedings of SIGCOMM 88 (Stanford, CA, Aug. 1988), ACM. Prasad R.S., Dovrolis C., and B. A. Mah B.A., The effect of layer-2 store-and-forward devices on per-hop capacity estimation, in Proc. IEEE INFOCOM, Mar. 2003, pp. 2090-2100. Jain, M., Dovrolis, K.: End-to-end Estimation of the Available Bandwidth Variation Range. In: SIGMETRICS'05, Ban_, Alberta, Canada (2005). Crovella, M.E. and Carter, R.L.: Dynamic Server Selection in the Internet. In: Proc. of the Third IEEE Workshop on the Architecture and Implementation of High Performance Communication Subsystems (1995). N. Hohn, D. Veitch, K. Papagiannaki and C. Diot, Bridging Router Performance And Queuing Theory, Proc. ACM SIGMETRICS, New York, USA, Jun 2004. Kleinrock, L. Queueing Systems, vol. II. John Wiley & Sons, 1976. Georgatos, F., Gruber, F., Karrenberg, D., Santcroos, M., Susanj, A., Uijterwaal, H. and Wilhelm R., Providing active measurements as a regular service for ISP's. In: PAM2001.

ВЛИЯНИЕ ИСКАЖЕНИЙ КЛЮЧЕВЫХ КАДРОВ НА ПЕРЕДАЧУ ВИДЕО В БЕСПРОВОДНЫХ СЕТЯХ Е.С. Сагатов, А.А. Семенов, Т.Н. Устенкова, А.М. Сухов Самарский государственный аэрокосмический университет имени академика С.П. Королева E-mail: [email protected] Введение Мобильные решения в области телекоммуникаций все более настойчиво входят в повседневную жизнь. Современные сотовые телефоны уже позволяют выполнять те же задачи, что и обычные компьютеры. Ноутбуки и нетбуки дают невероятную степень мобильности. Благодаря их компактности и наличию встроенных 3G, WiFi, а зачастую и WiMAX сетевых адаптеров можно быть на связи где угодно и когда угодно. Согласно данным Cisco VNI [1] ежегодный прирост Интернет-трафика на беспроводных устройствах составляет более 250%. К 2013 году количество данного трафика увеличится в 66 раз по сравнению с 2008 годом и составит 5,4% от всего IP-трафика в Интернет. К 2013 году различный видеоконтент будет составлять 64% всего трафика беспроводных сетей в мире. 51

Существует серьезное препятствие для повседневного использования видеосервисов в беспроводных сетях: соответствующее качество связи оставляет желать лучшего. Большой процент потерь пакетов и вариация задержки (сетевой джиттер) делают беспроводные сети малопригодными для передачи данных в режиме реального времени, так как мультимедийный трафик чрезвычайно чувствителен к подобным искажениям. Пакеты потокового видео теряются при передаче по сети, изменяют порядок следования из-за значительной вариации задержек пакетов. На получаемом видеоизображении появляются множественные артефакты, происходит рассинхронизация потока, что приводит к искажениям изображения, а иногда и к полной остановке воспроизведения видео. Методика паспортизации пакетных сетей в рекомендации RFC-2544 [3] определяет следующие основные параметры качества сети: пропускная способность, задержка при передаче пакета, пакетный джиттер, количество потерянных пакетов, количество пакетов с ошибками. Идея субъективного тестирования (MOS) состоит в том, что видео, закодированное одним из кодеков MPEG-2, MPEG-4 или Windows Media Video 9, передается через сеть Интернет и беспроводную сеть стандартов WiFi, 3G или WiMAX. Полученное после передачи видео, демонстрируется группе экспертов, которые выставляют оценки, основываясь на своих впечатлениях от качества. Существует много методов демонстрации последовательностей и сбора оценок, некоторые из них описаны в рекомендациях ITU [5]. К сожалению, в основном они рассчитаны на сравнение видео в телевизионном формате, и не очень удобны для проведения тестирования на PC. В настоящей работе рассматривается проблема адаптации современных алгоритмов кодирования и передачи видео для беспроводных сетей, таких как 3G, WiFi и WiMAX, а также для других сетей с плохими характеристиками качества. В работах [6, 7] было показано, что субъективная оценка качества видео, равно как и сетевых параметров, имеет градацию "хорошо" (Good), "приемлемо" (Acceptable) и "плохо" (Poor) (GAP). Такое описание помогает понять качественные зависимости, возникающие при сетевой трансляции видео и сделать первичные численные приближения. В настоящей работе сделана попытка найти численную зависимость качества видеоизображения от сетевых параметров. Отличительной особенностью нашего подхода является то, что указанная зависимость описывается простой математической моделью, что позволяет нам сравнить численные значения коэффициентов. На основании подобного сравнения возможно найти не только наиболее существенные факторы, влияющие на качество видео, но также и сопоставить между собой различные кодеки. В работе учитывается различие между искажениями, которые вносят повреждения ключевых и обычных кадров. Ключевым называется кадр, который несет в себе полную информацию о видеоизображении и может быть восстановлен без привлечения дополнительных данных, а обычным – кадр, который кодирует разницу между предыдущим кадром и текущим. Степень сжатия ключевого кадра меньше, чем обычного, а размер в несколько раз больше. В настоящей работе будет дано численное сравнение влияния ошибок, произошедших на ключевых кадрах, для кодеков MPEG-2 и MPEG-4. Настоящая работа организована следующим образом: Раздел 1 рассказывает о предпосылках для математического моделирования зависимости качества видео по шкале MOS от характеристик сетевого соединения, в Разделе 2 проводится планирование экспериментов, результаты обработки экспериментов приводятся в Разделе 3, Раздел 4 рассказывает о численных результатах эксперимента и параметрах математической модели, в заключении делаются выводы. 1. Предпосылки для моделирования При передаче видео по сети качество связи ухудшается в зависимости от характеристик сетевого соединения. Для того чтобы описать качество передаваемого видео в зависимости от сетевых , описывающая качество видео параметров была рассмотрена универсальная функция по шкале MOS. Эта функция может быть разложена в степенной ряд по сетевым параметрам, при этом можно ограничиться линейными членами и только одним вкладом второго порядка, описывающим передачу видео с различными скоростями потока. На конференции TERENA 2005 [4] было показано, что для фиксированной скорости видео потока достаточно рассмотреть только члены разложения, описывающие линейную зависимость от потерь пакетов и сетевого джиттера: (1) где • •

– максимальное качество видео для данного кодека, баллы от одного до пяти;

•

p – процент потерь пакетов, %; j – сетевой джиттер (вариация задержки) в момент ошибки, сек; Q MOS – качество видео на приемной стороне, баллы от одного до пяти;

•

α, β

•

– коэффициенты модели, которые могут быть найдены экспериментально.

Для проведения исследований была разработана единая видеопоследовательность, которая обрабатывалась кодеками MPEG-4 (DivX), MPEG-2 и Windows Media video 9 с постоянным битрейтом 256 кбит/с. Основная задача, поставленная в настоящей работе, это выявление влияния ключевых кадров на качество получаемого видеоизображения. Поэтому отдельно вычисляются коэффициенты 52

и

для

Труды конференции Телематика’2010

потока с повреждением ключевых кадров, а также

и

для последовательностей без повреждения

ключевых кадров. Например, будет обозначать усредненный коэффициент, который характеризует ухудшение качества видео, закодированного кодеком MPEG-4 (DivX), если повреждение пришлось на ключевой кадр. Далее в работе будут найдены и сопоставлены и

и

, а также

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

2. Планирование эксперимента Для нахождения коэффициентов уравнения (1) нами был разработан и проведен ряд экспериментов. Закодированные кодеками MPEG-4 (DivX), MPEG-2 и Windows Media Video 9 видеофайлы пересылались на ноутбук, подключенный к беспроводной сети WiFi, WiMAX или 3G. На ноутбуке проводилась запись получаемого видео в файл, параллельно записывался сетевой трафик на уровне пакетов при помощи сетевого сниффера Wireshark. Таким образом, по полученному видеоизображению можно установить качество видео по шкале MOS, а по сетевым логам – параметры сетевого соединения. Для проведения и анализа экспериментов (рис. 1) применялось программное обеспечение: • VLC media player [8] – использовался в качестве программного видеосервера и видеоплеера с возможностью записи получаемого по сети видео в файл на ноутбуке. • The Wireshark Network Protocol Analyzer [9] – с его помощью на ноутбуке записывался весь сетевой трафик, а затем анализировался. • VirtualDub [10] – с помощью данной программы производился покадровый анализ видеоизображения для вычисления MOS. • AviSynth 2.5 [11] – с его помощью в программе VirtualDub анализировалось видео, закодированное WMV кодеком. Данный кодек работает, используя технологию DirectShow, а не VFW (Video For Windows), и не может быть напрямую открыт в VirtualDub. Все записанные в ходе экспериментов видеофрагменты и сетевые логи опубликованы на сайте компании НПЦ «Интернет ТВ» [2]. Для сетей Wi-Fi, WiMAX и 3G эксперименты будут выглядеть одинаково, меняется лишь сетевое оборудование. На рисунке 1 представлена схема проведения эксперимента.

Рис. 1. Схема проведения эксперимента Для эксперимента был подготовлен один видеоряд с различными типами изображения: статичное, со слабым движением, с быстрым движением, с изменением яркости. Затем видеоряд был закодирован с использованием кодеков MPEG-4 (DivX), MPEG-2 и Windows Media Video 9. При этом установлены следующие параметры видео: • разрешение картинки – 320 x 240; • частота кадров – 24 кадр/с; • битрейт 256 кбит/с; • качество – максимальное. Файлы исходного видео также опубликованы на сайте компании НПЦ «Интернет ТВ» [2]. В качестве программы для трансляции видео по сети использовался программный продукт VideoLan VLC. Данная программа запускалась с сервера, подключенного к сети Интернет с реальным IP-адресом. На компьютере, который принимал видео, был установлен VLC media player, а также сетевой сниффер Wireshark, записывающий весь получаемый по сети трафик в момент передачи видео. VLC media player был настроен на одновременное отображение принимаемого видео на экран и сохранение его в видеофайл. Таким образом, при проведении каждого опыта записываются два файла для дальнейшего анализа: видеофайл и файл сетевых логов. 53

Для проведения экспериментов использовались – локальная сеть СГАУ (WiFi), самарские сегменты сети операторов связи: Мегафон (3G), Билайн (3G) и Метромакс (WiMAX), которые бесплатно предоставили оборудование и технические возможности для тестовых испытаний. 3. Обработка результатов экспериментов Для сети стандарта Wi-Fi характерно периодическое ухудшение характеристик сети, соответственно изображение ухудшается именно в определенные моменты. Порядок анализа всех полученных видеофрагментов и сетевых логов одинаков. Далее описан процесс анализа одного из видеофайлов и соответствующего ему файла сетевых логов в моменты ухудшения качества видео: 1) Программой VirtualDub открывается видеофайл (http://stream.ip4tv.ru/wireless/WiFi/test1/1divx.mp4), полученный в результате опыта. Ищется кадр, предшествующий искаженному кадру, на рисунке 2 видно, что это кадр 143, который отображается на 5923 мс видеоряда. Аналогично находится последний искаженный кадр, в описываемом случае это 171 кадр, показываемый на 7083 миллисекунде. Таким образом, вычитая из времени начала искажения видео время окончания, получится длительность искажения, составляющая 28 кадров или 1160 мс.

Рис. 2. Поиск искаженных кадров в VirtualDub 2) В сетевой сниффер Wireshark загружаются соответствующие логи сети (http://stream.ip4tv.ru/wireless/WiFi/test1/1divx.pcap), записанные в момент трансляции данного видео. Необходимо конкретизировать тип пакетов, выбрав пункт RTP. Во встроенном анализаторе приведен список всех пакетов и красным помечены места, где были потеряны пакеты. Также указаны статистические данные по межпакетному интервалу и джиттеру. Из столбца Sequence видно, что приняты пакет с номером 30195 и пакет с номером 30198, а между ними два пакета были потеряны. 3) Основная проблема анализа – как соотнести файл сетевых логов с видеозаписью. Для этого в логе пакетов ищется пакет (226), после которого произошла ошибка. По отношению к началу записи логов этот пакет поступил на 10,878914 секунде. В пункте 1 было найдено, что в видеоряде искажение произошло на 143 кадре, который отображался на 5923 мс видеоряда. Таким образом, искомое соотношение определено. 4) В пункте 1 установлено, что длительность искажений в видеоизображении 1160 мс. Соответственно от 226 кадра, пришедшего на 10,878914 секунде, отсчитывается 1160 мс. Получаем 12,038914 с. По сетевому логу Wireshark видно, что последний пакет, который пришел до 12,038914 секунды это пакет 253. 5) В Анализаторе RTP пакетов также указан межпакетный интервал и джиттер для каждого пришедшего пакета. Другая важнейшая задача, возникающая при обработке результатов экспериментов, это оценка качества видео по шкале MOS. Алгоритм оценки следующий: • На первом искаженном кадре видео и последнем устанавливаются метки в программе VirtualDub (рис. 2). • Искаженное изображение можно просматривать несколько раз и сравнить его с оригиналом. • Визуально оценивается качество видеоизображения в момент ошибки по шкале MOS от 1 до 5. 54

Труды конференции Телематика’2010

В настоящей работе для каждой ошибки свою оценку от 2 до 4 выставляли 4 эксперта. Затем по их оценкам вычислялось среднеарифметическое значение. При обработке файлов, закодированных при помощи кодека WMV9, возникли сложности. К сожалению, программа VirtualDub не отображает ключевых и неключевых кадров для видео, закодированного кодеком Windows Media Video 9. Поэтому эксперименты с ним не были нами обработаны. 4. Результаты экспериментов Полученные в результате проведения экспериментов данные были обработаны по описанной в предыдущем разделе методике. Найдено субъективное качество видео в зависимости от процента потерь пакетов таблицу 1.

и сетевого джиттера

. Полученные значения коэффициентов сведены в

Таблица 1. Значения коэффициентов модели для кодеков MPEG2, DivX в сети WiFi № пп 1 2

Кодек MPEG2 DivX

4,2±0,2 4,7±0,2

0,15±0,03 0,27±0,05

0,011±0,002 0,013±0,003

0,04±0,01 0,13±0,02

0,003±0,001 0,01±0,002

Было установлено, что качество видеоизображения зависит не только от процента потерь пакетов и сетевого джиттера, но и от типа кадра, на котором произошла ошибка. Поэтому в таблице 1 нами специально выделено два типа коэффициентов – с потерями на ключевых кадрах и без них. В таблице 1 и – коэффициенты модели с потерями пакетов на ключевых кадрах, и – коэффициенты для неповрежденных ключевых кадров, а – оценка по шкале MOS для исходного файла (до пересылки по сети). Изначально у видеоизображения, закодированного кодеком MPEG-4 (DivX), качество выше, чем у видео, закодированного MPEG-2, но при ухудшении характеристик сети качество снижается ощутимее и при больших сетевых помехах становится схожим с качеством MPEG-2. В случае повреждения ключевого кадра качество изображения, закодированного MPEG-4 (DivX) упадет более чем в 2 раза при тех же характеристиках сети, а MPEG-2 в 3,75 раза. Таким образом, для значительного повышения качества видеоизображения при передаче в беспроводной сети необходимо выполнить два обязательных пункта по модернизации схемы связи: • Модернизировать видеоплейер на приемной стороне с тем, чтобы автоматически откидывать дублирующиеся RTP пакеты. • Сервер потокового видео должен дублировать пакеты, содержащие информацию ключевых кадров. • Период между ключевыми кадрами не может превышать 2 секунд (оптимально 1 секунда). Эти простые меры приведут к тому, что даже плохие по оценке GAP сети будут транслировать видео с оценкой MOS большей 3,5. Стоит отметить, что для кодеков MPEG-4 (DivX) и MPEG-2 передаваемый объем трафика увеличится в среднем на 7%, а качество видео не менее чем в 2 раза. Некоторые исследованные видеоплееры при воспроизведении MPEG-TS MPEG-4 потоков уже автоматически отбрасывают повторяющиеся кадры, что дает принципиальную возможность повышения визуального качества передаваемого видео путем незначительной модификации алгоритма MPEG-TS инкапсуляции на сервере трансляций. К сожалению, на данный момент эксперименты в беспроводных сетях третьего и четвертого поколений еще не обработаны. Эксперименты, проведенные на сети WiMAX, показали очень хорошую устойчивость данной сети к ухудшению качества связи. Сети WiMAX по своим характеристикам сопоставимы с фиксированными сетями Ethernet. 3G сети очень чувствительны к внешним помехам и даже при хорошем уровне сигнала присутствуют значительные потери пакетов (Poor) и вариация задержки порядка 40 мс (Acceptable). Также было установлено, что у одного из 3G провайдеров оборудование зачастую дублировало исходящие пакеты, что само по себе создавало на видео очень сильные артефакты. Устранить данные помехи поможет наше решение с дублированием, а значит и отсеиванием дублированных кадров. Решение с дублированием ключевых кадров должно значительно повысить качество видео при передаче его в ненадежных из-за расстояния и шумов сетях, таких как WiFi и 3G. Также данное решение может быть применено в беспилотных разведывательных самолетах и спутниках, так как организовать для них надежный беспроводной канал связи для передачи видео очень сложно. Выводы В данной работе было проанализировано качество передачи видео в беспроводных сетях стандартов WiFi, 3G и WiMAX и исследовано влияние искажения ключевых кадров на качество видео. Оказалось, что сеть WiMAX достаточно надежна и по характеристикам соответствует проводной локальной сети. На сетях WiFi и 3G качество видео изображения значительно снижается при передаче. Для повышения качества видео в этих сетях нами предложен метод дублирования ключевых кадров сервером потокового видео при использовании кодека MPEG-4 (DivX). Это увеличит качество видео на сетях WiFi и 3G минимум в 2 раза при незначительном увеличении размера потока на 7%. Кроме того 55

данный метод может повысить качество видео за счет модернизации воспроизводящего плейера функцией отсеивания дублирующихся кадров. В работе были найдены коэффициенты математической модели, описывающей качество передачи видео [4] для случая беспроводной сети WiFi и кодеков MPEG-2 и MPEG-4 (DivX). Для расчета значений коэффициентов была разработана специальная экспериментальная методика, которая позволила собрать и обработать данные. В наши ближайшие планы входит изучение возможности подачи патента на сформулированные нами пункты по улучшению кодеков. Также мы планируем связаться с разработчиками свободно распространяемого программного обеспечения – VideoLan, чтобы внести изменения в исходные коды плейера и сервера потокового видео. В заключение хотелось бы выразить благодарность самарским отделениям операторов связи: Мегафон, Билайн и Метромакс, которые бесплатно предоставили оборудование и технические возможности для проведения экспериментов. Литература 1. Cisco Systems, Cisco Visual Networking Index: Forecast and Methodology, 2008–2013”, 9 июня 2009. (http://www.cisco.com/en/US/ solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11481360.pdf) 2. “Traces of video stream in wireless networks (WiMAX, 3G, WiFi)”. (http://www.ip4tv.ru/stati/aaa.html) 3. S. Bradner, J. McQuaid, RFC2544 - Benchmarking Methodology for Network Interconnect Devices, March 1999. 4. A. Sukhov, P. Calyam, W. Daly, A. Ilin, Towards an analytical model for characterizing behavior of highspeed VVoIP applications, Computational Methods in Science and Technology, 11(2), 161-167 (2005). 5. International Telecommunication Union, “Methodology for the subjective assessment of the quality of television pictures (ITU-R BT.500-11)” (2002). 6. M. Claypool and J. Tanner, “The Effects of Jitter on the Perceptual Quality of Video,” in ACM Multimedia, 1999. 7. P. Calyam, M. Sridharan and et. al., “Performance Measurement and Analysis of H.323 Traffic,” in PAM Workshop, 2004. 8. VideoLAN team, “VideoLAN, Free streaming and multimedia solutions for all OS!”. (http://www.videolan.org/) 9. Wireshark Foundation, “Wireshark. Go deep”. (http://www.wireshark.org/) 10. Avery Lee, “Welcome to virtualdub.org! - virtualdub.org”. (http://www.virtualdub.org/) 11. “Main Page - Avisynth”. (http://avisynth.org/mediawiki/Main_Page)

ФУНКЦИЯ РАСПРЕДЕЛЕНИЯ ЗАДЕРЖКИ ПАКЕТОВ В ГЛОБАЛЬНОЙ СЕТИ Н.Ю. Кузнецова, А.К. Первицкий, А.М. Сухов Самарский государственный аэрокосмический университет им. С.П. Королева, г. Тольятти E-mail: [email protected], [email protected], [email protected] В работе показано, что для описания процесса передачи пакетов в сети следует использовать экспоненциальное распределение. Статистическая проверка гипотезы показала, что параметры распределения остаются постоянными в течение минимум 500-секундного интервала. В работе в явном виде записаны функция распределения и генерирующая функция для задержки пакетов сети, приведен алгоритм поиска параметров распределения. Введение Специальная область теории управления, названная сетевые системы управления (networked control system), где в качестве среды, переносящей управляющие сигналы, служат компьютерные сети, возникла во второй половине 90-х годов [15]. Первоначально в качестве сетевой среды использовались локальные сети, которые характеризуются высокой скоростью передачи данных и минимальными сетевыми искажениями [6]. Позже, в качестве управляющей среды стала рассматриваться и глобальная сеть Интернет [7, 12, 14], однако в этом случае необходимо учитывать как случайных характер пакетной задержки, так и достаточно большие (десятки и даже сотни миллисекунд) средние величины. Кроме классических задач теории управления, существует потребность управления и мониторинга сетевых процессов. Например, для передачи видео в сетях TCP/IP важным параметром является доступная полоса между двумя хостами [3], а для задач определения маршрутизации необходимо знать пропускную способность между маршрутизаторами. Для моделирования большинства сетевых процессов применяются специальные сетевые эмуляторы, например, INET/OMNET++ [13]. Все вышеперечисленные задачи управления требуют знания типа распределения задержки пакетов. В 1999 году Elteto и Molnar [5] провели исследования двухсторонней задержки в сети оператора Эриксон. 56

Труды конференции Телематика’2010

Это распределение соответствовало усеченному нормальному распределению с некоторыми нарушениями в виде «тяжелых хвостов». Наши собственные эксперименты по измерению доступной полосы [11] показали, что существует минимальная неустранимая часть и переменная часть пакетной задержки. Предпосылки для моделирования В 1999 Downey [4] обнаружил линейную зависимость двухсторонней задержки пакетов в сети (Round Trip Time) от их размера. В 2004 уточняющие эксперименты групп во главе Choi [2] и Hohn [8] показали, что минимальная задержка размера:

D где

для пакета размера fixed

h

h

i =1

i =1

(W ) = W ∑ 1 / Ci + ∑ δ i

является аффинной функцией его

,

(1)

Ci – пропускная способность канала на соответствующем участке маршрута, δ i – физическая

задержка прохождения пакета. Для подтверждения этого предположения экспериментально находилась минимальная задержка пакетов одинакового размера для трех разных маршрутов и строилась функция в зависимости задержки от размера пакета Пусть

D(W )

W.

представляет собой время передачи пакета (задержка, One Way Delay) между двумя есть минимальное задержка для пакета размером W.

хостами в глобальной сети. Следовательно,

D fixed (W ) = min D(W )

(2)

Для того чтобы определить переменную компоненту задержки часть

из задержки текущего пакета

d var (W )

вычтем фиксированную

D(W ) :

d var (W ) = D (W ) − D fixed (W ) (3) Для минимальной задержки пакета размером W справедливо следующее выражение: D fixed (W ) = Dmin + W / C , (4) где C = (W2 − W1 ) /( D2 − D1 ) – пропускная способность канала. Она находится, сравнивая среднее время задержки для пакетов разных размеров W 2 и W1 [11]. Dmin = lim D fixed (W )

(5)

W →0

Наличие

Dmin

объясняется распространением сигнала с конечной скоростью, ограниченной

D

сверху скоростью света, временем обработки пакетов на маршрутизаторах и т.д. Величина min показывает минимальную задержку для пакетов заданного размера, с которой тот может быть передан по сети из пункта отправки в пункт назначения. В ходе эксперимента данная величина может быть рассчитана по следующей формуле: fixed fixed 2 2 1 1 min 2 1 (6)

D

=

WD

(W ) − W D W −W

(W )

Эта величина, так же как методы ее измерения используется в прикладных задачах теории управления трафиком [1], например, для расчета временного буфера для видеопотока на приемной стороне. Важнейший вопрос теории управления является тип распределения для переменной части задержки из уравнения (3), который и будет исследоваться в оставшейся части статьи. Планирование эксперимента Для определения типа распределения переменной компоненты задержки

d var (W )

необходимо

провести значительное количество измерений (от 100 до 5000) с высокой точностью. Основной проблемой получения таких данных является необходимость максимально точного измерения задержки. 57

Подобные измерения требуют, как минимум, микросекундной точности, достигнуть такой точности стало возможным благодаря использованию механизма RIPE Test Box [10]. RIPE Test Box – это измерительная система, разработанная организацией RIPE (Réseaux IP Européens). RIPE ведет распределение IP-адресов, регистрацию LIR (Local IP Registry) и автономных систем, определяет общие для Европы правила регистрации доменов. В период 2006-2008 нами были установлены три измерительные точки в Москве, Самаре и Ростове-на-Дону. Установка происходила в рамках Гранта РФФИ 06-07-89074. Всего к настоящему времени на территории России развернуто 4 точки [1], в Самаре точка RIPE Test Box была смонтирована в начале 2007 года в межвузовском медиацентре г. Самара. Три другие точки: управляющий узел FREENet в Институте органической химии Российской Академии Наук в Москве, Институт теоретической физики РАН в Черноголовке Московской области и региональная точка обмена трафиком Rostov-IX. В ходе эксперимента между серверами в Амстердаме (Голландия, tt01.ripe.net), Самаре (Россия, tt143.ripe.net), Москве (Россия, tt146.ripe.net), Болонье (Голландия, tt17.ripe.net) и Мельбурне (Австралия, tt74.ripe.net) были собраны соответствующие данные, точность измерений составила не менее 10 мкс [10]. Результаты этих экспериментов получены на RIPE Test Box при помощи удаленного доступа по порту 9142 и доступны для использования на сайте www.ip4tv.ru [9]. При проведении эксперимента важно зафиксировать информацию одновременно на обеих сторонах исследуемого маршрута. На основе полученных от RIPE Test Box данных легко построить функцию распределения для сетевой задержки

D(W ) : F ( D) = P ( x ≤ D)

(7)

Для первоначальной проверки были выбраны усеченное нормальное и экспоненциальное распределения. Для усеченного нормального распределения будет использоваться следующая функция распределения:

0, D ≤ Dmin ;

F (D) =

(8)

2/π

σ

где

σ

⎧ ( x − Dmin ) ⎫ exp ∫ ⎨⎩− 2σ 2 ⎬⎭dx, D > Dmin , D min D

2

σ = Dav − Dmin ,

(9)

– разница между усредненной величиной сетевой задержки

задержкой

Dav (W )

и минимальной

Dmin (W ) .

Важно отметить, что все статистические данные были собраны нами для фиксированной длины пакета

W.

По умолчанию RIPE Test Box использует пакеты размером 100 байт. В дальнейшем

F (W , D)

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

F (D) = где

0, D ≤ 0; 1 − exp{− λ ( D − Dmin )}, D > Dmin ,

λ = 1 /( Dav − Dmin )

(10)

(11)

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

Dav (W )

и минимальной задержкой

Dmin (W ) .

Первоначальная проверка Для первоначальной проверки типа распределения были использованы два метода: вычисление коэффициента корреляции Пирсона и графический метод. Корреляционный коэффициент между 58

Труды конференции Телематика’2010

экспериментальным

и

нормальным

распределением

обозначим

как

K nor ,

корреляционный

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

K exp .

Собранная с серверов статистика была обработана, полученные данные представлены в таблице 1. В столбце Маршрут отображается информация о том, между какими точками RIPE Test Box были проведены измерения,

W

обозначает размер посланных пакетов.

Таблица 1. Значения коэффициентов корреляции Пирсона для нормального и экспоненциального распределения №

Маршрут

, байт

1

Амстердам – Болонья, tt01→ tt17

100

0.76

0.97

2

Амстердам – Самара, tt01→ tt143

100

0.87

0.98

3

Амстердам – Самара, tt01→ tt143

1024

0.99

0.99

4

Амстердам – Мельбурн, tt01→ tt74

100

0.66

0.97

Графический метод предусматривает сравнение полученных графических представлений функций распределения (cumulative distribution functions, CDF). Изобразим все три функции на одном графике, выделив цветом каждое из распределений. Синий цвет отображает экспериментальную кривую, черный цвет нормальное распределение, а красный экспоненциальную зависимость.

Рис. 1. Зависимость функции распределения задержки пакетов размером 100 байт (tt01 → tt143)

Рис. 2. Зависимость функции распределения задержки пакетов размером 1024 байта (tt01 → tt143) Графики, представленные на рисунках 1 и 2, показывают функцию распределения задержки между измерительными точками в Амстердаме и Самаре (tt01 -> tt143). Первый график описывает эксперимент, 59

проводимый со 100-байтными пакетами, а второй с пакетами размером 1024 байта. Время на оси времени отложено в миллисекундах. Полученные предварительные результаты дали возможность предположить, что распределение, описывающее задержку пакетов в глобальной сети, описывается экспоненциальной функцией. Однако не каждый исследователь или инженер имеет такие механизмы точного измерения, как RIPE Test Box. В этой работе описан метод, позволяющий провести похожие эксперименты по определению параметров распределения, используя стандартную утилиту ping. Эта утилита является наиболее распространенной и доступной для проверки сетевых соединений в TCP/IP сетях. Отметим, что эта утилита измеряет двухстороннюю задержку пакета (Round-trip Time, RTT), наша модель описывает задержку только в одном направлении. В качестве предельного случая можно считать, что

D(W ) = RTT (W ) / 2

(12)

Однако следует помнить о несимметричном характере двухсторонней задержки. При помощи утилиты ping были протестированы соединения между точками Аист – Новая Зеландия (tt47.ripe.net), Волгателеком – Мельбурн (tt74.ripe.net) и СГАУ – Мельбурн (tt74.ripe.net). Аист, Волгателеком, Инфолада и СГАУ это локальные самарские провайдеры, сети которых использовались при тестировании. Полученные результаты представлены в таблице 2. Таблица 2. Результаты тестирования сетевых каналов с помощью утилиты ping №

Маршрут

1

Аист – Новая Зеландия

32

0.94

0.95

2

Волгателеком – Мельбурн

32

0.96

0.98

3

СГАУ – Мельбурн

64

0.66

0.97

4

Инфолада – Афины

32

0.98

0.98

, байт

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

Dav (W )

и

Dmin (W )

из уравнений (9, 11). Таким образом, полностью определяются

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

χ 2 Пирсона.

Для обработки были использованы несколько наборов данных от 2000 до 2500 значений задержки, собранные с интервалом в 2 секунды. Эти данные разбивались на интервалы в 50, 100, 250, 500, 1000 и 2000 значений и тестировались по Пирсону. Результаты тестирования занесены в Таблицы 3,4. При построении этих Таблиц использовались следующие обозначения: – размерность выборки (число измерений), – число интервалов группировки выборки

, по правилу Стургерса

N = [1 + 3,22 lg n] + 1 ,

– значение статистики по Пирсону, 2 0.95, N −1 – значение порога принятия гипотезы.

χ

Если

t < χ 20.95; N −1 , то гипотеза о соответствующем типе распределения принимается, иначе

гипотеза отвергается. Вначале проверим на соответствие экспоненциальному распределению данные, получение при помощи RIPE Test Box, см. таблицу 3.

60

Труды конференции Телематика’2010

Таблица 3. Самара – Амстердам (tt143→ tt01), размер пакета 100 байт Размер выборки, Число интервалов группировки, Порог, χ 0.95, N −1 2

Значение статистики, Принятие гипотезы

50

100

200

250

500

1000

2000

14

17

19

20

22

24

27

22.36

26.30

28.87

30.14

32.67

35.17

38.89

21.29

25.35

22.77

23.10

134.31

547.16

978.98

Да

Да

Да

Да

Нет

Нет

Нет

Из таблицы 3 следует, что в пределах 500 секундных интервалов (250 измерений) задержка пакетов распределена по экспоненциальному закону. Данные, полученные с RIPE Test Box, проверялись также на соответствие усеченному нормальному распределению, см. табл. 4.

Таблица 4. Самара – Амстердам (tt143→ tt01) размер пакета 1024 байт 50

100

200

250

500

1000

2000

14

17

19

20

22

24

27

Порог, χ 0.95, N −1

22.36

26.30

28.87

30.14

32.67

35.17

38.89

Значение статистики, Принятие гипотезы

43.32 Нет

217.46 Нет

2906.47 Нет

6077.07 Нет

∞ Нет

∞ Нет

∞ Нет

Размер выборки, Число интервалов группировки, 2

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

F (D) =

будет выглядеть следующим образом:

0 , D ≤ D min + W / C ;

1 − exp {− λ ( D − D min − W / C ) }, D > D min + W / C , (13)

а определено в уравнении (11). Важно отметить, что данные по задержке, полученные с использованием пакетов различной длины, содержит в себе дополнительную переменную составляющую, обусловленную сетевым джиттером (вариацией задержки). При использовании утилиты ping для определения параметров распределения, необходимо запускать ее с ключами, позволяющими фиксировать размер пересылаемых пакетов (-l в Windows и -s в Linux). Представленная в этой работе модель имеет еще одно применение. Результаты могут быть применены для написания эмуляторов трафика в глобальной сети, например для INET/OMNET++[13]. Основываясь на итоговом типе распределения задержки, найденном выше (уравнение 10), можно найти генерирующую функцию для описания задержки:

D = Dmin + W / C − (1 / λ ) ln(1 − F ( D, W )) (14) В этой формуле, значение функции распределения F ( D, W ) может быть задано генератором случайных чисел. Полученные значения будут описывать величину задержки для сетевых пакетов различного размера. Еще раз стоит отметить, что в реальных сетях параметры распределения могут быть найдены с использованием утилиты ping или утилит, измеряющих задержку

.

61

Выводы В настоящей работе показано, что для описания процессов задержки пакетов в глобальных сетях, следует выбирать экспоненциальное распределение. В отличие от усеченного нормального распределения оно проходит проверку статистическими методами. Следует отметить, что время, в течении которого параметры распределения остаются неизменными не превышает 10 минут. Экспериментальные данные были собраны с помощью измерительной системы RIPE (с точностью до микросекунд, механизм NTP – протокол точного времени). В целях поиска параметров распределения возможно использование стандартной утилиты ping с точность до миллисекунды. В работе найдена генерирующая функция для пакетной задержки в сетях протокола TCP/IP, которая может быть использована в эмуляторах трафика глобальных сетей. Литература 1. Платонов А.П., Сидельников Д.И., Стрижов М.В., Сухов А.М., Измеpительная инфpастpуктуpа для изучения качества соединений в pоссийском сегменте Интеpнет, Телекоммуникации, 2009, № 1, с.11-16. 2. Choi, B.-Y., Moon, S., Zhang, Z.-L., Papagiannaki, K. and Diot, C.: Analysis of Point-To-Point Packet Delay In an Operational Network. In: Infocom 2004, Hong Kong, pp. 1797-1807 (2004). 3. Dovrolis C., Ramanathan P., and Moore D., Packet-Dispersion Techniques and a Capacity-Estimation Methodology, IEEE/ACM TRANSACTIONS ON NETWORKING, Vol. 12, No. 6, DECEMBER 2004, p. 963-977. 4. Downey A.B., Using Pathchar to estimate internet link characteristics, in Proc. ACM SICCOMM, Sept. 1999, p. 222-223. 5. Elteto, T., Molnar, S., On the distribution of round-trip delays in TCP/IP networks, in The Proceedings of the Local Computer Networks (LCN ’99) Conference, IEEE, 1999, pp. 172–181. 6. Georges J.-P., Divoux T., Rondeau E., Confronting the performances of a switched ethernet network with industrial constraints by using the network calculus, International Journal of Communication Systems(IJCS), 2005, vol. 18, no. 9, pp. 877-903. 7. Hespanha J.P., Naghshtabrizi P., Xu Y., A survey of recent results in networked control systems, Proceedings of the IEEE, 2007, vol. 95, pp. 138-162. 8. N. Hohn, D. Veitch, K. Papagiannaki and C. Diot, Bridging Router Performance And Queuing Theory, Proc. ACM SIGMETRICS, New York, USA, Jun 2004. 9. http://www.ip4tv.ru/a1.html. 10. Ripe Test Box, http://ripe.net/projects/ttm/. 11. A.M. Sukhov, T.G. Sultanov, M.V. Strizhov, A.P. Platonov, Throughput metrics and packet delay in TCP/IP networks, RIPE59 Meeting, Lisbon, 2009; arXiv:0907.3710. 12. Y. Tipsuwan, M.-Y. Chow, Control methodologies in networked control systems, Control Engineering Practice, 2003, vol. 11, pp. 1099-1111. 13. A. Varga. The OMNeT++ distrete event simulation system, Software on-line: http://whale.hit.bme.hu/omnetpp/, 1999. 14. Zampieri S., Trends in networked control systems, Proceedings of the 17th World Congress, The International federation of Automatic Control, July 2008. 15. W. Zhang, M.S. Branicky, S.M. Phillips, Stability of Networked Control Systems, IEEE Control System Magazine, 2001, v. 21, no 2, p. 84-99.

МОДИФИКАЦИЯ, МОДЕЛИРОВАНИЕ, АНАЛИЗ И ВЕРИФИКАЦИЯ ПРОТОКОЛА СЕМЕЙСТВА WIRELESS ACCESS PROTOCOL М.М. Алексеева, Е.А. Дашкова, Д.Ю. Чалый Ярославский государственный университет им. П.Г. Демидова E-mail: [email protected] Аннотация Важность сетей передачи данных и мультимедиа информации невозможно переоценить сегодня, в начале информационной эпохи развития человечества. Системы сбора, обработки и распределения информации являются важнейшей точкой приложения научного знания. Наиболее актуальной задачей в коммуникации стала спецификация и верификация коммуникационных протоколов, а также повышение их эффективности. В связи с развитием мобильных систем беспроводные сети передачи данных пользуются спросом. Благодаря развитию технологий беспроводной передачи данных разработчики аппаратного и программного обеспечения предлагают широкий спектр новых сервисов, например, мобильный интернет. Нововведения должны быть полезными, удобными, гибкими в использовании, быстрыми, предоставляющие безопасность и с минимальным количеством ошибок при исполнении. Одной из технологий, обеспечивающих доступ к мобильному интернету, является стек протокола WAP. Аббревиатура WAP расшифровывается как Wireless Application Protocol, т.е. протокол 62

Труды конференции Телематика’2010

беспроводного приложения, или Wireless Access Protocol – протокол беспроводного доступа. Второй вариант точнее отражает сущность технологии WAP, назначение которой – обеспечить доступ к информации, находящейся непосредственно в Интернете. Авторы предлагают модификацию транспортного уровня протокола WAP (Wireless Transaction Protocol – WTP), улучшение алгоритма управления потоком. Работа включает в себя новые идеи разработки и совершенствования WAP, как одной из важных технологий. Мы используем симулятор сети NS2, который предоставляет возможность построения сетевых протоколов и моделирования их поведения. I. Введение В начале 21-го века компьютерные сети стали важнейшим средством общения. Беспроводные сети являются одним из самых популярных методов общения, распространяясь по всему миру и помогая людям общаться. Существует несколько протоколов, которые обеспечивают доступ к беспроводному интернету. Одним из наиболее популярных протоколов является протокол WAP (Wireless Access Protocol) [6]. Наиболее точное определение технологии WAP – обеспечить доступ к информации из интернета для мобильных устройств, имеющих следующие характеристики: • небольшой объем памяти устройств; • небольшой размер экрана телефона, а также ограниченные условия ввода; • низкая скорость работы процессора; • низкая пропускная способность канала связи; • возможность появления продолжительных таймаутов. WAP был разработан для решения этих проблем, в этом состоит его основное отличие от HTTP и TCP/IP. Заметим, что пользователь не использует дополнительные устройства, такие как модем. WAP – это протокол, который описывает, каким образом информация из интернета отображается на небольшом экране мобильного телефона. Стек протокола WAP содержит несколько уровней. Согласно модели OSI (Open Systems Interconnection) [8] WAP содержит шесть уровней: уровень приложений (Application Layer), сеансовый уровень (Session Layer), уровень транзакций (Transaction Layer), уровень безопасности (Secure Layer), транспортный уровень (Wireless Transaction Protocol) и физический уровень (Bearers). Каждый уровень предназначен для выполнения строго определенных функций. В данной работе мы ориентируемся на транспортный уровень, модифицируя алгоритм управления потоком в WAP с использованием идей, лежащих в основе алгоритма ARTCP [1]. Этот протокол предлагает новый метод управления потоком на основе управления скоростью передачи сегментов в сеть. Протокол ARTCP (Adaptive Rate Transmission Control Protocol) заимствует некоторые механизмы протокола TCP, который является основным транспортным протоколом интернета. Протокол ARTCP отличается от стандартного TCP тем, что сегменты отправляются в сеть не в виде всплеска в пределах окна, а разделенные временными промежутками, длительность которых определяется текущим значением скорости. Скорость потока регулируется не размером переменного окна, а значением скорости, изменением которой осуществляется адаптация алгоритма в соответствии с условиями сети. Проверка свойств нового алгоритма производится с помощью симулятора сети. Существует два подхода к моделированию: аналитический подход и симуляционный. Сейчас идет заключительная стадия построения модели модифицированного протокола WTP с использованием NS2, который дает возможность построения сетевых протоколов и моделирования их поведения. II. Основная часть A. Системное моделирование. NS2 Симуляция широко используется в моделировании систем для приложений, начиная от инженерных исследований, бизнес-анализа, планирования производства и научных экспериментов в области биологии [5]. При построении подобной модели сети связи могут использоваться как статические, так и динамические модели. При этом под статическими понимаются модели, используемые для исследования состояния сети в заданные моменты времени, например, аналитические методы расчета из теории массового обслуживания, а под динамическими – дискретные стохастические модели, например, процессы генерации заявок или процессы их обслуживания. Сегодня для решения задач имитационного моделирования сетей связи существует достаточно широкий спектр программных средств: от библиотек функций для стандартных компиляторов до специализированных языков программирования [7]. Имеется некоторое множество примеров, которые показывают, что различные показатели производительности можно снимать с модели в терминах раскрашенных сетей Петри. CPN/Tools – это инструмент, который позволяет визуально редактировать, выполнять и анализировать раскрашенные сети Петри (CPN – Colored Petri Nets). Однако в CPN/Tools используются не классические раскрашенные сети Петри – добавлено время и используется встроенный язык программирования CPN ML (на основе Standard ML). Поэтому, на наш взгляд, наиболее перспективным специализированным пакетом для исследования различных характеристик производительности протоколов является пакет Network Simulator. NS2 позволяет строить модели коммуникационных протоколов практически любой сложности, построено ряд моделей протоколов, созданных непосредственными разработчиками протоколов, что говорит о высоком уровне моделей, построенных с помощью данного симулятора [2]. 63

Симулятор сети Network Simulator (версия 2), широко известный как NS2, является событийно-управляемым инструментом моделирования, весьма полезным при изучении динамического характера коммуникационных сетей. NS2 предоставляет пользователям способ задания таких сетевых протоколов и моделирования их поведения. NS2 позволяет создавать различные виды трафика: от простейших, подчиняющихся пуассоновскому закону, до самоподобных. Несомненным достоинством данного симулятора для случая беспроводной сети является его возможность при помощи генератора сценариев определить передвижение узлов. Также стоит отметить встроенную возможность анимации результатов проведения различных сценариев. Полная и упрощенная версии NS2 содержат средство анимации результатов моделирования nam (Network Animator) реализованное на Tcl/Tk, и только полная версия NS2 содержит программное средство Xgraph, позволяющее графически отображать результаты моделирования. Что существенно упрощает работу по визуализации результатов (не требуется установка дополнительных программных приложений специально для обеспечения наглядности работы). Работа в NS2 предполагает два этапа. Первым шагом является построение модели с использованием программирования на C++, и 2-й шаг – использование TCL для анализа модели и моделирования условий работы сети, что позволяет нам включить программный код на С++ в среду NS2 (рис. 1) [3]. Мы считаем, что NS2 - наиболее удобное средство для моделирования протоколов и поведения сети.

Рис. 1. Архитектура NS2 B. WTP Уровень WTP (Wireless Transaction Protocol) стека протокола WAP отвечает за надежную доставку сообщений. Maximum Transfer Unit (MTU) – максимальный размер пакета в сети. Если имеется сообщение большего размера, чем MTU, тогда WTP фрагментирует это сообщение. Существует три класса работы по этому протоколу. В данной работе мы ориентируемся только на второй класс операций (class-2) для Wireless Transaction Protocol [5]. Управление потоком в случаях фрагментированных сообщений осуществляется отправкой фрагментов в группах. В каждой группе пакетов требуется только одно подтверждение для группы. Последний пакет каждой группы содержит специальный флаг. Этот флаг указывает на конец группы и получатель знает, когда нужно отправить подтверждение. Размер каждой группы зависит от характеристик связи и памяти устройства. Необходимо избегать дополнительной отправки пакетов и потери данных. Получатель отправляет «негативное» подтверждение (NAK), если конечный пакет группы получен, в то время как промежуточные пакеты отсутствуют. Эта операция повторяется до тех пор, пока вся группа не будет получена и не отправится «позитивное» подтверждение (ACK). Если время ожидания подтверждения истекло, только последний пакет группы посылается повторно, и отправитель знает, какие пакеты были утрачены. Wireless Transaction Protocol пытается свести к минимуму количество ненужных повторов передачи пакетов [4]. C. Модель протокола Расширенная сегментация и сборка протокола WTP используют как алгоритм скользящего окна, так и механизм stop and wait [6]. Идеи алгоритмов скользящего окна и stop and wait являются стандартными решениями для транспортных протоколов, но возможно улучшение стандартов или разработка более эффективных аналогов. Алгоритм управления потоком протокола ARTCP использует схему скользящего окна наряду с оригинальным механизмом ARTCP. Основным достоинством алгоритма ARTCP является то, что он не интерпретирует потерю данных только как перегрузку сети и тем самым позволяет избежать нежелательного снижения эффективности работы сети. В модели основной акцент делается на три параметра, которые мы будем увеличивать или уменьшать в зависимости от работы сети. Пусть ts – это временной интервал между последовательно 64

Труды конференции Телематика’2010

отправляемыми пакетами одной группы, которые отправляются от отправителя (sender) к получателю (receiver); tr – интервал между последовательно принимаемыми пакетами одной группы, которые принимаются получателем: tr = tr-1*alfa+(1-alfa)*t', где alfa =1/( Amp -1), t' = (now - trl), now – текущий момент времени, trl – время прибытия последнего пакета; Amp – число пакетов в группе. В модели имеется два типа подтверждений: «позитивное» (ACK) и «негативное» (NAK) (рис. 2). Когда получатель отправляет подтверждение, он передает tr с помощью этого подтверждения. Отправитель вычисляет отношение ts/tr. В зависимости от результата этого отношения имеется несколько ситуаций для анализа и дальнейших действий. Первая ситуация ts/tr =1 отражает идеальные условия сети. Вторая ситуация 0.85< ts/tr <1. Все параметры могут быть модифицированы увеличением Amp, уменьшением ts и таймаута: Amp = 2* Amp (экспоненциально увеличиваем Amp); ts = ts/2 (экспоненциально уменьшаем ts); timeout = timeout /2 (экспоненциально уменьшаем таймаут);

Рис. 2. Схема работы Мы заключаем, что если 0,70< ts/tr <0,85, то не имеется достаточно данных, чтобы принять решение, как изменить параметры (условия сети соответствуют установленным параметрам). Четвертая ситуация ts/tr < 0,70 – сеть переполнена, все параметры могут быть модифицированы уменьшением Amp, увеличением ts и таймаута: Amp = Amp/2 (экспоненциально уменьшаем Amp); ts = 2* ts (экспоненциально увеличиваем ts); timeout = 2* timeout (экспоненциально увеличиваем таймаут); III. Заключение Экономическая выгода от повышения эффективности коммуникационных протоколов, таких как WAP, может оказаться очень существенной, особенно с учетом дальнейшего роста и развития коммуникационных систем. WAP в том виде, в котором он существует сейчас, требует серьезного усовершенствования. Нами разработан новый метод управления потоком, основанный на управлении 65

скоростью передачи сегментов в сеть, количеством единовременно отправляемой информации и временем ожидания ответа от получателя. Авторы пришли к выводу, что алгоритмы управления потоками данных используют недостаточное количество характеристик сети и поэтому сталкиваются с одними и теми же ошибками: перегрузка в сети, последующая потеря или искажение данных. Выдвинута идея анализа дополнительных характеристик сети с последующим ее улучшением в зависимости от полученных данных. Проводя анализ транспортного уровня (Wireless Transaction Protocol – WTP) протокола WAP, можно сделать вывод, что механизм управления потоком можно сделать гибче, адаптируя к изменяющимся условиям беспроводной среды. Беспроводные каналы характеризуются высоким уровнем ошибок и узкой полосой пропускания канала, поэтому часто происходят перегрузки в сети (вследствие увеличения ожидания ответа от получателя или потери данных). Изучены слабые стороны механизма управления потоком нескольких протоколов, также внесены изменения в структуру передаваемых пакетов, добавлена дополнительная информация в заголовок пакета, внесены изменения в число ключевых функций протокола, которые отвечают за отправку и получение пакетов и установку таймаутов. В будущем планируется создание протокола на основе проанализированной и верифицированной модели. Благодарности Статья подготовлена в рамках участия авторов в семинаре Finnish – Russian University Cooperation in Telecommunications Program (FRUCT). Авторы благодарят декана факультета информатики и вычислительной техники Ярославского государственного университета им. П.Г. Демидова П.Г. Парфенова за интерес и поддержку данного проекта и научного руководителя центра «Центр инновационного программирования» профессора В.А. Соколова за ценные советы. Литература 1. И.В. Алексеев, В.А. Соколов, Д.Ю. Чалый “Моделирование и анализ транспортных протоколов в информационных сетях”, Ярославский государственный университет, 2004. 2. В.А.Соколов, Д.Ю. Чалый, “Методы исследования поведения транспортных протоколов в условиях интенсивного сетевого трафика”, Распределенные информ.-вычисл. ресурсы и мат. моделирование, МКВМ-2004, С.129. 3. T. Issariyakul, E. Hossain, “Introduction to Network Simulator NS2”, DOI: 10.1007/978-0-387-71760-9 1, Springer Science + Business Media, LLC 2009, p.20-23. 4. C. Ladas, R. M. Edwards AMIEE, G. Manson “WAP performance on an end-to-end scheme”, The Centre for Mobile Communications Research (C4MCR), The University of Sheffield. 5. http://www.isi.edu/nsnam/ns/. 6. http://www.openmobilealliance.org/Technical/wapindex.aspx – WAP specification. 7. Е.А. Кучерявый “NS-2 как универсальное средство имитационного моделирования сетей связи”, Tampere University of Technology, Telecommunications Laboratory, Tampere, Finland. 8. Э. Таненбаум “Компьютерные сети”, – СПб., Питер, 2003. – 992 с. 9. Aust Stefan, Nikolaus A. Fikouras, Görg Carmelita “Enabling Mobile WAP Gateways using Mobile IP”, Department of Communication Networks (ComNets), Center for Information and Communication Technology (IKOM) University of Bremen, Germany. 10. Moon Il-Young “Performance Analysis of WAP Packet Transmission Time and Optimal Packet Size in Wireless Network”, School of Internet Media Engineering, Korea University of Technology and Education, Republic of Korea. Springer-Verlag, Berlin Heidelberg, 2006. 11. http://nile.wpi.edu/NS/.

66

Труды конференции Телематика’2010

Секция 2. Веб-технологии

ИНФОРМАЦИОННЫЙ ПОРТАЛ УЧЕБНО-МЕТОДИЧЕСКОЙ ЛИТЕРАТУРЫ НА БАЗЕ ЛОКАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ (ЛВС) Е.А. Кандрин, А.А. Кузнецов, Д.В. Андрейко, А.И. Нейфельд Алтайский государственный университет, г. Барнаул E-mail: [email protected] В современном мире в связи с широким распространением информационных технологий, происходило массовое внедрение технических средств в образовательный процесс. Традиционно процесс образования делится на три части: • Теоретическая часть включает в себя курс лекций, проводимых в аудиториях. Информация, преподносимая учащимся, отбирается и фильтруется лектором. • Практическая часть, лабораторный практикум состоит из занятий, проводимых в аудиториях, или в специально оборудованных помещениях в виде учебного эксперимента. • Самообучение заключается в более углубленном изучении материалов самостоятельно. Как показывает мировая практика обучения, такая система образования позволяет студентам эффективно усваивать учебный материал. Однако, каждая часть процесса образования, описанная выше, нуждается в учебно-методическом материале. Классический способ распространения таких материалов – это книги, методические пособия, записи, полученные учащимися на лекциях. С развитием технологий развивались и новые технические средства распространения информации. Эти средства широко внедрялись в учебный процесс и получили название технические средства обучения (ТСО). Традиционно под техническими средствами подразумевают: видеомагнитофоны; аудиомагнитофоны; проекторы; интерактивные доски; и т.д. Аудиомагнитофон позволяет прослушать речь носителя языка. Видеомагнитофон расширяет курс практикума с помощью учебного фильма, наглядно демонстрирующего учебный эксперимент. Все это касается теоретического и практического аспектов процесса образования. Самообразование же требует от учащегося самостоятельного поиска учебных материалов, посещения библиотек, которые зачастую находятся на значительном расстоянии и имеют ряд проблем с получением доступа к литературе. Эти проблемы частично решены с помощью ЭВМ, способной хранить большие объемы информации различного рода: текст, видеоматериалы, системы контроля знаний и т.д. Прямое применение этих средств улучшает построение образовательного процесса, но не привносит качественного изменения в его характер, так как их использование только совершенствует техническую базу. Кроме того, на современный образовательный процесс значительное влияние оказывают глобальные сети. Обилие информации создает проблемы ее фильтрации и поиска. Для решения этих проблем необходим системный подход, с помощью которого технологии будут интегрированы в единую систему, реализуя тем самым целостность процесса образования. Известные на сегодняшний день системы качественно не меняют подход в предоставлении и организации доступа информации. В основном это сводится к переводу бумажных материалов в цифровой вид и создание общего доступа к ним. Приведем примеры некоторых из них. Wikipedia – свободная общедоступная многоязычная универсальная интернет-энциклопедия, запущенная в январе 2001 года Джимми Уэйлсом и Ларри Сэнгером. Она реализована по технологии создания сайтов – wiki. Достоинства технологии – это редактирование любой страницы и создание новых страниц, используя веб-браузер без каких-либо расширений, поддержка перекрестных ссылок, удобный язык разметки для редактирования текста, легкость внедрения, масштабируемость, бесплатность (opensource). К минусам можно отнести то, что wiki не является полностью доработанным ресурсом, так как главная идея wiki – это привлечение пользователей к непрерывному процессу создания и редактирования страниц. Как следствие, любой имеет возможность вносить изменения, что может повлиять на качество материала и его достоверность. Электронно-библиотечная система «КнигаФонд», созданная в соответствии с поручением Президента Российской Федерации № 576 от 2 апреля 2008 г. «КнигаФонд – инструмент образовательной системы, обеспечивающий широкий легальный доступ к необходимой для образовательного процесса литературе. Доступ предоставляется на основании прямых договоров с правообладателями». Достоинства проекта – удобная система поиска, регулярное пополнение каталога, систематизация учебного материала, создание неограниченного количества собственных конспектов, содержащих как цитаты из книг, так и собственные записи, создание закладок, создание личной книжной полки для постоянно используемых в работе книг. К минусам можно отнести возможность доступа только через сеть интернет, платный доступ к ресурсу вследствие легального доступа, невозможность внедрить систему в рамках ЛВС учебного заведения, большой отклик системы на действия пользователя [1]. 67

Электронный портал учебно-методического материала на основе веб-форума. Веб-форум предоставляет услуги общения посетителей веб-сайта. Он состоит из набора разделов, в которых пользователю предоставляется возможность создавать темы с последующим их обсуждением. На такой основе можно организовать иерархическую структуру данных, перекрестные ссылки, а такие достоинства, как обсуждения, поиск, система регистрации пользователей, разграничение доступа, система обмена личными сообщениями уже включены в базовый состав веб-форума, также стоит отметить легкую внедряемость, масштабируемость, бесплатность. К минусам можно отнести то, что интерфейс веб-форума направлен в первую очередь на общение посетителей, нежели на создание портала для учебно-методического материала, для внедрения нового функционала будет необходимо изменять структуру веб-форума. Кроме индивидуальных недостатков, у всех вышеперечисленных систем можно выделить и общие: • отсутствие иерархического структурированного представления данных; • отсутствие фильтрующих средств информации; • отсутствие централизованного доступа к информации; • отсутствие комплексного подхода к получению информации. Описанный ниже проект «Информационный портал учебно-методической литературы на базе ЛВС учебного заведения» учитывает достоинства и исправляет, по крайней мере, большинство вышеперечисленных недостатков. Такой портал должен выполнять следующие функции: • фильтрующие средства информации; • централизованный доступ к информации; • комплексный подход к получению информации; • иерархическое структурированное представление данных; • удобный поиск; • обратную связь в виде комментариев; • контроль знаний в виде системы тестов; • систему создания и редактирования учебных материалов; • использование перекрестных ссылок; • легкость внедрения, масштабируемость, расширяемость. Информационный портал учебно-методической литературы на базе ЛВС должен быть построен как система управления контентом. Такая система предоставляет возможность создания, редактирования и удаления учебных материалов. Для того чтобы работать с системой управления контентом, пользователь должен обладать правами редактирования. Система управления контентом предоставляет средства визуального форматирования текста, возможность добавления аудио и видео материалов, прикрепление файлов известных форматов (формат пакета MS Office, Open Office.org, файлы PDF, DJVU, изображения и прочих мультимедиа форматов), содержащих учебные пособия, методические материалы, конспекты, лекции и т.п. Добавление контента производится в иерархическую структуру, которая, например, для вуза будет представлять собой: Î факультеты Î кафедры Î преподаватели Î предметы Î учебные материалы. Исходя из выше приведенной структуры, авторизированным пользователем, вносящим изменения в контент, будет преподаватель. Для них доступна личная панель, где будут отображаться элементы управления: • добавить материал в предмет; • редактировать данные о предмете; • удалить предмет. Также будут отображаться элементы управления добавления нового предмета и материала. В каждом предмете в виде списка отображаются материалы с элементами управления: • редактирование материала; • удаление материала. Предметы и учебные материалы отсортированы в алфавитном порядке и в порядке последнего изменения. Если преподаватель работает на разных факультетах, то ему предоставлена возможность выбора факультета. Для системы разработаны правила добавления и удаления контента. Она допускает перекрестные ссылки. Доступ к системе осуществляется через главную страницу. Перед тем, как пользователю будут доступны ресурсы портала, ему необходимо пройти авторизацию. На титульной странице размещается краткая информация о портале и форма авторизации. После прохождения авторизации открывается главная страница (рис. 1).

68

Труды конференции Телематика’2010

Рис. 1. Модульная сетка главной страницы Главную страницу визуально можно поделить на блоки: • блок 1 – хедер; • блок 2 – навигационное меню учебно-методической части (левая колонка); • блок 3 – навигационное меню сайта (левая колонка); • блок 4 – информационный блок (центральная часть); • блок 5 – футер. Блок 1 состоит из логотипа и строки поиска. Блок 2 содержит в себе иерархическую структуру учебного заведения, позволяющая в два клика перейти к интересующему предмету. Блок 3 содержит в себе ссылки на разделы сайта. В зависимости от выбранного раздела, контент меню может изменяться. Блок 4 содержит 5 последних новостей портала, а также 5 последних изменений в учебнометодической части портала. Блок 5 включает в себя правовую информацию о разработчиках и дублированные разделы меню сайта. Модульная структура портала Система в целом состоит из модулей, каждый из которых является законченной программной единицей. Это позволяет развивать систему с помощью добавления новых модулей, либо редактирования уже существующих, не теряя основного функционала системы. На рис. 2 изображена модульная структура портала, где в иерархическую последовательность с вертикальными связями объединены модули: модуль авторизации, модуль интерфейса, модуль управления учебнометодическими материалами, модуль тестов, модуль новостей и комментариев, модуль администрирования, модуль базы данных (БД).

69

АВТОРИЗАЦИЯ

   

преподаватель

студент

администратор

                                                                                  

Система  управления  УММ* 

Система  управления  тестами 

ИНТЕРФЕЙС  Панель   администрирования 

Новости Комментарии

 

     

Тест  n

Поиск

  УММ 1 

УММ 2 

УММ n 

Тест  2 Тест  1

  БД ИПУММ**    Рис. 2. Общая структура портала Рассмотрим более подробно каждый из модулей Информационного портала учебно-методического материала: Модуль авторизации определяет, какими правами будет обладать пользователь после входа в систему. Есть три вида пользователей: студент, преподаватель и администратор. Студент имеет право просматривать и скачивать учебно-методические материалы, выполнять тесты контроля знаний и оставлять комментарии. Преподаватель имеет право создавать, удалять и изменять свои предметы, учебные материалы и тесты, а также он имеет все права студентов. Администратор управляет иерархической структурой сайта, что позволяет легко настраивать систему для любого образовательного учреждения на начальном этапе внедрения. Он управляет новостями, учетными записями пользователей, так же может удалить любой материал, не соответствующий моральным и правовым нормам. Модуль интерфейса делится на две части: • Графическая оболочка. • Функциональная часть, взаимодействующая с модулями низкого уровня – система управления учебно-методическими материалами (СУУММ), система управления тестами (СУТ), модулем новостей и комментариев, модулем администрирования. Интерфейс объединяет функционал всех модулей и предоставляет пользователю информацию в соответствии со строго регламентированными правилами. Отображаемая информация зависит от прав пользователя, полученных при авторизации. Помимо описанных выше функций, модуль интерфейса 70

Труды конференции Телематика’2010

структурирует полученную информацию для вывода по трем основным аспектам образовательной модели (теоретическая, практическая, самостоятельная части). Модуль управления учебно-методическими материалами представляет собой промежуточное звено между интерфейсом пользователя и БД. Позволяет модулям верхнего уровня обращаться к БД для создания, просмотра, редактирования и удаления учебно-методических материалов. Создание данного модуля делает систему легко расширяемой, т.к. существует возможность изменять модуль базы данных без внесения изменений в модуль интерфейса. Модуль управления тестами представляет собой промежуточное звено между интерфейсом пользователя и БД. Он решает поставленную задачу контроля знаний. Позволяет модулям верхнего уровня обращаться к БД для создания, редактирования, удаления и прохождения тестов. Так же данный модуль выдает и сохраняет статистику, и если указано, то отправляет ее на электронный адрес создателя теста. Модуль новостей и комментариев позволяет работать с новостями и комментариями. Он обеспечивает обратную связь с пользователями. Модуль администрирования представляет собой набор средств и методов для администрирования портала. Пользователь с правами администратора сайта реализует (ручную) фильтрацию информации. Модуль поиска. Предоставляет расширенные инструменты по поиску информации в базе данных по различным критериям: • поиск материала по автору; • поиск материалов по предмету; • поиск материалов по ключевым словам; • и т.д. Модуль БД. Хранит учетные записи пользователей и информацию о них, учебно-методические материалы в структурированном виде, тесты и результаты их выполнения, комментарии, новости, статистику портала. Такая структура системы позволяет самостоятельно изучать учебные материалы, консультироваться с преподавателями. Благодаря продуманной иерархии, доступ к нужной информации организуется буквально в несколько кликов. Благодаря правилам добавления учебных материалов организуется удобная структура перекрестных ссылок, которая играет важную роль в междисциплинарной подготовке. Перекрестные ссылки имеет двухуровневую структуру: при наведении на ссылку появляется краткое определение термина, а при нажатии – переход в соответствующий раздел. Новые определения и термины заносятся в предметный глоссарий. Так же по каждому предмету существует система самоконтроля знаний в виде тестирования. Для реализации проекта были выбраны современные технологии построения веб-порталов: • PHP – основной язык, на котором реализуется функционал портала. • JavaScript позволяет создавать интерактивные веб-страницы. • Технология AJAX позволяет ускорить взаимодействие веб-браузера (клиента) с сервером. • HTML – стандартный язык для разметки веб-страницы, будет использоваться для создания шаблонов веб-страницы. • SQL – язык структурированных запросов к БД. Необходимое программное обеспечение для портала: • Веб-сервер Apache, обладающий надежностью и гибкой конфигурацией. • СУБД MySQL, которая является оптимальным решением для построения системы управления БД. Выбор ПО обусловлен тем, что оно является свободным и кроссплатформенным, а в сочетании с ОС Linux, которая не требовательна к ресурсам ПК и также является свободной, сводит расходы к нулю. В ходе реализации проекта были решены все поставленные задачи. В итоге был получен продукт «Информационный портал учебно-методического материала», являющийся универсальным инструментом для объединения трех основных аспектов образовательного процесса: • теоретическая часть; • практическая часть и лабораторный практикум; • самообучение. Портал обладает следующими свойствами: расширяемость благодаря продуманной модульной структуре, внедряемость и масштабируемость вследствие выбранных средств разработки и языков программирования, комплексным подходом в получении информации. Литература 1. Электронная библиотека КнигаФонд [Электронный ресурс]: вся литература для образовательного процесса – Режим доступа: http://www.knigafund.ru/, свободный. – Загл. с экрана.

71

К ВОПРОСУ ПРОЕКТИРОВАНИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ УЧЕБНЫМ ПРОЦЕССОМ ВУЗА О.А. Бубарева Бийский технологический институт (филиал) Алтайского государственного технического университета, г. Бийск E-mail: [email protected] В данной статье приведены принципы построения, структура и описание автоматизированной системы управления учебной деятельностью вуза. Подробнее рассматриваются подсистемы планирования учебного процесса и расчета себестоимости образовательной услуги. Введение Современное управление деятельностью вуза обеспечивается созданием единой информационной среды для поддержки образовательных, научно-исследовательских и организационно-управленческих процессов. При этом задачи управления образовательным процессом относится к классу сложных, слабоформализуемых, решение которых невозможно без использования современных средств информационной поддержки. Решаются эти задачи в рамках Интегрированных Автоматизированных Информационных Систем (ИАИС), обеспечивающих функции оперативного и стратегического управления основными видами вузовской деятельности и представляющих собой сложные организационно-технические структуры, базирующиеся на основе использования систем баз данных (БД). Разработок в области автоматизации процессов, протекающих в вузах, существует немало, но далеко не всегда университет имеет возможность приобрести информационную систему (ИС) необходимого уровня, не говоря уже о том, что внедрение сторонних разработок и адаптация программного продукта к особенностям конкретной организации всегда порождает множество проблем. Готовые системы такого рода, разработанные в университетах, которые можно было бы использовать в качестве базовых, являются слабо документированными и плохо адаптируемыми к особенностям вуза; единственная система, отличающаяся отсутствием указанных недостатков – система «Университет» требует серьезных финансовых затрат, а также наличия в вузе коллектива высокопрофессиональных специалистов в области ИТ, что в большинстве случаев нереально; предлагаемые коммерческими структурами системы внешне выглядят привлекательно (в т.ч. и по цене), но на поверку оказываются недоработанными и плохо адаптируемыми без участия разработчиков к конкретной среде их функционирования [1]. В Бийском технологическом институте создана основа интегрированной автоматизированной информационной системы (ИАИС), в составе которой реализован комплекс функциональноориентированных подсистем [2]. Каждая подсистема ориентирована на определенные виды деятельности и реализует определенные функции управления вузом. В состав функциональной подсистемы входит множество самостоятельных модульных элементов, выполняющие необходимые задачи. Особое место в ИАИС занимает подсистема автоматизированного управления учебным процессом, обеспечивающая поддержку приемной кампании, планирование учебной работы, учет контингента студентов и выпускников, модульно-рейтинговый анализ успеваемости, расчет себестоимости образовательных услуг [3]. 0 Автоматизированная система управления учебным процессом вуза

01 Подсистема Приемная кампания

031 Подсистема Учебные планы

72

02 Подсистема Контингент студентов

03 Подсистема планирования учебного процесса

032 Подсистема Расчет и распределение учебной нагрузки кафедр

033 Подсистема Индивидуальные планы преподавателей

04 Подсистема Расчет себестоимости ОУ

034 Подсистема Расписание

05 Подсистема модульнорейтингового анализа успеваемости

035 Подсистема Учета учебной нагрузки ППС кафедры

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

Труды конференции Телематика’2010

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

Рис. 2. Диаграмма потоков данных подсистемы планирования учебного процесса Применение автоматизированной системы управления учебным процессом вуза позволяет уменьшить временные затраты в процессе планирования и управления деятельностью вуза, получить оперативный доступ к информации, сопровождающей учебный процесс для принятия эффективных управленческих решений, повысить эффективность управления образовательным процессом и образовательным заведением в целом. Подсистема «Учебные планы» Для каждого вновь набираемого контингента студентов по специальности или направлению в подсистеме «Учебные планы» составляется учебный план на весь срок обучения. Он идентифицируется названием специальности (направления) и годом поступления. В данной подсистеме автоматизировано составляются рабочие (семестровые) учебные планы на планируемый учебный год. Для расчета трудоемкости изучения дисциплин студента используется методика перевода учебных часов в кредиты ECTS [4], основанная на экспертных данных, что позволяет получить более сбалансированные результаты. Подсистема «Расчет часов учебной нагрузки ППС» С помощью подсистемы «Расчет часов учебной нагрузки ППС» занятия объединяются в потоки, с учетом имеющегося в вузе аудиторного фонда, и закрепляются за кафедрами. В соответствии с данными учебных и рабочих учебных планов очной и заочной форм обучения формируются сметы, отчеты, графики подготовки электронных учебно-методических комплексов. Полученный комплект рабочих учебных планов является основой для расчета штатов профессорскопреподавательского состава и определения учебной нагрузки кафедр. На основании полученных данных формируется штатный формуляр, который затем используется в подсистемах управления финансовохозяйственной деятельностью и поддержки принятия решений при составлении и анализе сметы расходов на организацию учебного процесса на планируемый учебный год, а также при расчете себестоимости образовательной услуги (ОУ). 73

Подсистема «Распределение учебной нагрузки по преподавателям кафедр» Следующим этапом задачи планирования учебной нагрузки кафедр является распределение ее по преподавателям с использованием подсистемы «Распределение учебной нагрузки по преподавателям кафедр». Также в данной подсистеме реализована возможность распределения учебной нагрузки по руководству аспирантами. Сведения о студенте поступают из подсистемы «Абитуриент» на основании приказа о его зачислении в вуз, при этом устанавливается связь с учебным планом, в соответствии с которым он будет обучаться. Учебный план определяет список дисциплин, по которым в базу данных заносятся сведения об успеваемости студента. В течение учебного года ведется оперативный учет движения контингента студентов в соответствии с приказами, а также учет текущей (рейтинг) и сессионной успеваемости. Подсистема «Расписание» В подсистеме «Расписание» реализована одна из важных и наиболее трудоемких задач планирования учебного процесса – это автоматизированное составление расписания занятий и экзаменационных сессий. При наличии сети и единой корпоративной базы данных вуза дополнительных документов для составления расписания не требуется, все необходимые данные незаметно и органически вписываются в существующие документы, не искажая, а дополняя сложившиеся формы. Исходные данные для составления расписания получаются попутно с обычной учетно-плановой работой. В качестве основы используются два основных документа – рабочий учебный план и сведения о распределении нагрузки между преподавателями. Подсистема «Расписание» реализует ряд основных функций: • учет пожеланий преподавателей; • закрепление обязательных аудиторий; • указание желательных аудиторий; • учет перехода между корпусами; • учет учебных потоков и подгрупп. Помимо выше перечисленных функций, подсистема анализирует входные данные на предмет объединения учебных потоков и т.д., используемые в процессе составления расписания, и анализирует выходные данные – само расписание (определяя коэффициент рациональности (отношение вместимости аудитории на фактическую наполненность) использования аудиторного фонда и составляя рекомендации по распределению и планированию аудиторного фонда). Кроме того подсистема «Расписание» позволяет эффективно управлять распределением аудиторного фонда вуза посредством правильно построенных советов и рекомендаций по его использованию. При управлении распределением аудиторного фонда входными параметрами являются: • система рекомендаций по составлению расписания; • коэффициент сменности; • учебные потоки. Подсистема управления распределением аудиторного фонда анализирует эффективность использования имеющегося аудиторного фонда (с учетом таких факторов, как время использования, простоя, перегруженности и недостаточной загруженности аудиторий). Кроме того, подсистема выявляет причины нерационального использования аудиторий и степень их влияния на качество использования аудиторного фонда. Чтобы рационально сформировать учебные потоки, с точки зрения рационального использования аудиторного фонда, используются методы математического моделирования, позволяющие определить размер и число потоков, которые максимально соответствуют числу имеющихся аудиторий соответствующей вместимости. Подсистема «Расчет себестоимости образовательной услуги» Подсистема «Расчет себестоимости образовательной услуги» позволяет проводить расчет, анализ и прогнозирование себестоимости образовательных услуг (ОУ) в реальном времени с целью принятия эффективных управленческих решений для повышения качества образования. Данная подсистема позволяет производить расчет «контрактных» часов на основе подсистемы «Расчет и распределение учебной нагрузки», расчет стоимости одного часа преподавателя на основе данных ИС «Кадровый учет», расчет и анализ себестоимости оказания платных ОУ, прогнозирование рыночной стоимости ОУ, формирование отчетов в разрезе специальностей, форм обучения, курсов и кафедр. Многообразие используемых методик при расчете себестоимости ОУ обусловило необходимость разработки собственной модели представления системного описания структуры и семантики данных, представленное в виде метаданных. Основным положением, определяющим структуру системного описания, является то, что конечные пользователи должны работать не с множеством таблиц и столбцов БД, смысл и назначение которых зачастую известны только разработчикам, а с множеством взаимосвязанных типов объектов системы для описания необходимого алгоритма расчета себестоимости ОУ. То есть пользователи при работе с универсальными средствами должны иметь возможность использовать хорошо понятные им русскоязычные термины, обозначающие объекты системы, их свойства и связи. Основные параметры для расчета себестоимости ОУ: • учебная нагрузка преподавателя по дисциплинам для каждой группы; 74

Труды конференции Телематика’2010

• • • • • • • • • • • • •

контингент студентов, обучающихся по контрактной форме обучения в группах; контингент студентов, обучающихся по бюджетной форме обучения в группах; нагрузка часов преподавателей на ставку в год в зависимости от степени и должности; среднечасовая зарплата преподавателей (ППС); затраты на оплату учебно-вспомогательного персонала (УВП); коэффициент, устанавливающий соотношение между заработной платой УВП и ППС; коэффициент, учитывающий доплату «за неблагоприятные условия труда»; затраты на оплату административно-управляющего персонала; затраты на оплату прочего персонала; затраты на прочие статьи расходов вуза; коэффициент стимулирующих выплат в фонде оплаты труда; коэффициент материалоемкости каждого цикла дисциплин по кафедрам; коэффициент, устанавливающий принадлежность каждой кафедры к выпуску специальности или направлений бакалавриата. Также в подсистеме «Расчет себестоимости образовательной услуги» реализована база знаний, которая хранит сценарии и онтологию задач и методов определения того или иного параметра. Оперируя готовыми сценариями и параметрами, пользователь сам выстраивает необходимый алгоритм расчета себестоимости ОУ. Основными результатами реализации и внедрения подсистемы «Расчет себестоимости образовательной услуги» являются: • повышение эффективности использования автоматизированной системы управления учебным процессом за счет предоставления доступа к данным большему числу заинтересованных лиц; • сокращение расходов на автоматизацию и информационную поддержку разного рода алгоритмов по расчету себестоимости ОУ; • ускорение процессов ввода в эксплуатацию различных форм отчетности с использованием выбранного алгоритма. Для полноценной работы системы автоматизированного управления учебного процесса необходимо ее постоянное взаимодействие с другими подсистемами ИАИС вуза. С этой целью был разработан специальный модуль синхронизации данных с подсистемами «Контингент студентов», «Кадровый учет», расчета заработной платы и др. Модуль синхронизации позволяет соотносить данные, хранящиеся в отдельных таблицах базы данных [5]. При этом дублирующая информация удаляется либо консолидируется и соединяется, после принятия решения оператором. Заключение В настоящее время в стадии опытной эксплуатации находятся все перечисленные программные модули автоматизированной системы управления учебной деятельностью вуза, реализованные средствами 1С 7.7. Литература 1. Планирование учебной нагрузки ДО в рамках пакета "Plany" [Электронный ресурс] // в образовании. 2010. Режим доступа: Информационно-коммуникационные технологии http://www.ict.edu.ru/vconf/files/6910.doc. 2. Проблемы автоматизации и информатизации университетского управления/ Ф.А. Попов, Н.Ю. Ануфриева, А.Н. Заборовский, А.А. Тютякин // Сб. трудов XVI Всероссийской научно-методической конференция "Телематика’2009". – СПб: Изд-во СПбГУ ИТМО, 2009. 3. Бубарева, О.А. Разработка автоматизированной системы управления учебным процессом ВУЗа/ О.А. Бубарева, Ф.А. Попов, А.А. Тютякин// Сб. трудов III всероссийской научно-практической конференции "Фундаментальные науки и образование". – Бийск: БПГУ им. В.М. Шукшина, 2010. – С. 164-166. 4. Этапы большого пути. Болонский процесс в России [Электронный ресурс] // Этапы большого пути. Болонский процесс в России. 2010. Режим доступа: http://ru-ects.csu.ru/ru/node/11. 5. Бубарева, О.А. Интеграция информации в информационно-управляющих системах /Бубарева О.А., Попов Ф.А.// Информационные технологии в экономике, науке и образовании: материалы Всероссийской научной конференции 16-17 апреля 2009 г. В 2-х ч.; ч.1 / под ред. О.Б. Кудряшовой; Алт. гос. техн. ун-т, БТИ.-Бийск: Изд-во Алт. гос. техн. ун-та, 2009. – С. 69–70.

75

СИСТЕМА СБОРА И АНАЛИЗА СТАТИСТИКИ ОБРАЩЕНИЙ К МУЛЬТИМЕДИЙНОМУ КОНТЕНТУ ДЛЯ СИСТЕМЫ Genus Media Upshot А.А. Бегишев Новгородский государственный университет им. Ярослава Мудрого, г. Великий Новгород E-mail: [email protected] Введение Все большее число веб-проектов для привлечения аудитории используют мультимедийный контент. Удаленное обучение сейчас сложно представить без онлайн аудио и видеолекций. Социальные сети не конкурентоспособны без возможности публикации мультимедийных файлов пользователями. С ростом количества медиа-файлов возникает задача контролирования обращений к этим файлам. Целью разработанной системы является создание сервисов для сбора и анализа статистики просмотра мультимедийных файлов для системы управления мультимедийным контентом Genus Media Upshot. Что такое Genus Media Upshot? Система Genus Media Upshot служит для управления мультимедийными файлами (аудио, видео, документы и пр.) в корпоративных системах управления контентом (IBM FileNet, IBM Lotus Web Content Management и другие).

Рис. 1. Общая архитектура Genus Media Upshot Промышленные продукты, такие как IBM Lotus Web Content Management (WCM) и Lotus Connections поддерживают традиционный контент – текст, изображения, документы. Но работа с медиа-контентом требует вмешательства квалифицированного персонала в каждом случае, на каждом этапе – для загрузки, управления, перекодировки, публикации видео, аудио и другой мультимедиа информации. Система Genus Media Upshot предоставляет следующую функциональность для решения данных проблем: • Полноценное решение для загрузки, управления и публикации медиа-контента для IBM Lotus Web Content Management и Lotus Connections. • Автоматизирует загрузку и перекодировку видео роликов, доставку различного медиа-контента и потокового видео. • Может использовать различные системы хранения контента, в том числе IBM Content Manager, FileNet и CMIS-совместимые репозитории. • Предоставляет полнофункциональные веб-сервисы для управления медиа-контентом. Использование систем хранения контента обеспечивает ключевой функционал по управлению данными и их безопасности. Также это усиливает возможности по повторному использованию контента, поиску и просмотру. 76

Труды конференции Телематика’2010

Наличие API на базе веб-сервисов позволяет загружать медиа-файлы, просматривать хранилища данных, и публиковать наборы медиа-файлов. Поддержка протоколов REST и SOAP позволяет разработчикам быстро и легко внедрять медиа-контент и требуемый функционал в существующие или новые приложения. Назначение системы сбора и анализа статистики Из-за увеличения количества аудио и видеофайлов возникает задача сбора статистических данных по просмотру этих файлов. Решение данной задачи позволяет администратору следить за популярностью публикуемого контента. Так же часто возникает проблема контроля просмотров пользователями системы. Например, в случае дистанционного образования, можно контролировать просмотрел ли обучаемый пользователь учебное видео, просмотрел полностью или частично, когда просмотрел и так далее. Системы сбора и анализа статистики просмотра мультимедийного контента для системы управления мультимедийным контентом Genus Media Upshot позволяет собирать и хранить статистические данных по просмотру мультимедиа-файлов (рис. 1). На основе полученных данных могут быть сформированы текстовые и графические отчеты. Примеры возможных отчетов: • общее количество просмотров с графиком зависимости по времени; • общее количество полных просмотров (просмотр от начала до конца) с графиком зависимости по времени; • откуда осуществляются переходы к просматриваемому медиа-файлу; • количество просмотров по определенному медиа-файлу с графиком зависимости по времени; • количество полных просмотров по определенному медиа-файлу с графиком зависимости по времени; • список пользователей, просмотревших указанный медиа-файл, с возможностью указания диапазона воспроизведенных секунд видео/аудио клипа. Разработанная система не имеет полных аналогов в сфере сбора и анализа статистических данных по просмотрам мультимедийного контента среди публичных сервисов, однако включает в себя некоторые функции этих систем. Использованные инструменты Просмотр и воспроизведение аудио и видеофайлов осуществляется с помощью флеш-плеера FlowPlayer. Данный флеш-плеер имеет API для регистрации событий и создания дополнительных плагинов. События флеш-плеера FlowPlayer можно разделить на три категории: • события плеера; • события клипа; • события списка воспроизведения. События, регистрируемые плагином для сбора статистики: События плеера: onVolume

Возникает при изменении уровня громкости

onMute

Событие отключения звука (mute)

onUnmute

Событие обратное событию onMute

onFullscreen

Возникает при переключении режима плеера в полноэкранный режим

onFullscreenExit

События выхода из полноэкранного режима

События клипа: onBegin

Возникает в момент начала буферизации клипа

onFinish

Возникает в момент завершения воспроизведения при достижении конца клипа.

onPause

Возникает при нажатии на управляющую кнопку «Пауза»

onResume

Возникает

в

момент

начала

воспроизведения

после

остановки

воспроизведения с помощью «Паузы» onSeek

Возникает при изменении позиции воспроизведения (вперед/назад)

onBeforeSeek

Предшествует событию onSeek

onStart

Событие начала воспроизведения клипа

onStop

Событие остановки воспроизведения клипа.

onBufferFull

Возникает, когда клип буферизирован полностью

77

Хранение данных Хранение данных осуществляется с помощью IBM DB2. Она была выбрана, так как обладает достаточно хорошей производительностью при больших нагрузках и легко интегрируется с другими продуктами IBM, на основе которых работает система Genus Media Upshot. Формирование документа Отчет генерируется с помощью java-библиотеки JasperReports. Данная библиотека позволяет сформировать отчет по заранее подготовленному XML – шаблону, использующему определенную разработчиками DTD-схему документа. Отчет может быть сгенерирован в различных видах: HTML, PDF, DOC и другие. Для более наглядного представления данных в отчет могут быть включены графические диаграммы. Графические диаграммы можно создать двумя методами: • В JasperReports-шаблоне задать запрос на выборку из базы данных и описать, каким образом полученные данные будут использованы при построении диаграммы. • jFreeChart – позволяет генерировать графические диаграммы. Диаграмма, полученная данным методом, формируется отдельным подключаемым к шаблону классом, так называемым скриплетом. Скриплет расширяет класс JRDefaultScriptlet и может инициализировать параметры, определенные в JasperReports-шаблоне. Шаблон отчета может быть сгенерирован с помощью графического редактора iReport. Интерфейс предоставления отчетов Отчеты предоставляются пользователю посредством виджетов IBM Lotus Mashups Center. IBM Lotus Mashups предоставляет среду гибридных приложений, позволяющую объединять собственное, корпоративное и Web-содержимое для создания простых, гибких и динамических приложений. IBM Lotus Mashups включает в себя следующие компоненты: • Графическое средство на основе браузера, помогающее пользователям, имеющим необходимые знания о Web-технологиях, легко выполнять прозрачную компоновку новых приложений. • Каталог гибридных приложений, который поможет упростить совместное использование и поиск компонентов для гибридных приложений. Кроме того, каталог будет иметь встроенные функции для коллективной работы, такие как оценки, метки и комментирование. • Простая в использовании среда разработки для быстрого создания динамических виджетов. • Широкий выбор готовых к использованию виджетов. Виджет представляет из себя мини-приложение, которое подключается пользователем в своей рабочей области IBM Lotus Mashups Center. Описание работы системы Схематическое описание системы отражено на рис. 2. Регистрация и отправка события на сервер осуществляется с помощью разработанного для плеера FlowPlayer плагина. Информация о произошедшем событии (позиция воспроизведения, громкость, тип события и другая информация) отправляется в запросе (XMLHTTPRequest). Для обработки запроса используется сервлет, который позволяет безопасно записывать полученную информацию в базу данных. Получение отчета осуществляется через IBM Lotus Mashups Center. Пользователь должен добавить виджет для просмотра отчетов на рабочий стол Lotus Mashups Center. Окно виджета отображает HTMLверсию отчета и обновляется с заданной периодичностью. В режиме конфигурации виджета пользователь может задать необходимые критерии для формирования желаемого отчета. Заданные параметры сохраняются. Для обработки запроса, с параметрами запрашиваемого отчета, так же используется сервлет, который по заданным критериям генерирует документ с отчетом. Формирование отчета можно разбить на два этапа. На первом этапе подготавливается запрос по заданным критериям, делается выборка из базы данных. Результат выполнения запроса обрабатывается в соответствии с логикой отчета (подсчет данных, преобразование к нужному формату и так далее). На втором этапе происходит формирование документа (doc, html, pdf и другие). Данные полученные на первом этапе подставляются в JasperReports-шаблон. После чего сгенерированный отчет отправляется пользователю (рис. 3). Создание нового отчета В системе сбора и анализа статистики просмотра мультимедийного контента для системы управления мультимедийным контентом Genus Media Upshot предусмотрена возможность добавления новых отчетов. Для добавления нового отчета разработчик должен создать на основе предоставляемых интерфейсов пакет классов, которые будут реализовывать бизнес-логику отчета. Так же для генерации документа с отчетом нужно создать JasperReports-шаблон. Для предоставления доступа к новому отчету через виджет IBM Lotus Mashups Center нужно добавить новый отчет в список известных отчетов, который хранится в XML-файле.

78

Труды конференции Телематика’2010

Рис. 2. Общая схема взаимодействия системы с пользователем (темно-серым цветом обозначены разработанные компоненты)

Рис. 3. Процесс получения отчета пользователем Заключение Разработанная система обеспечивает мониторинг воспроизведения аудио и видео контента, публикуемого с помощью Genus Media Upshot. Возможность получения отчета в различных форматах позволяет делать сохранение данных в удобном для дальнейшего использования виде. Архитектура системы предусматривает возможность генерации шаблона отчета налету. Литература 1. 2. 3. 4.

Genus Technologies – официальный сайт разработчиков Genus Media Upshot. http://www.genusllc.com IBM enterprise mashups – IBM Mashup Center – страница поддержки. http://www01.ibm.com/software/info/mashup-center/ Flowplayer - Flash Video Player for the Web – официальный сайт http://flowplayer.org/ Open Source Business Intelligence – Jaspersoft – официальный сайт разработчиков JasperReports. http://www.jaspersoft.com/ 79

РАЗРАБОТКА СЕРВЕРНОЙ ГЕОИНФОРМАЦИОННОЙ СИСТЕМЫ ПО МОДЕЛИРОВАНИЮ ДИНАМИКИ ЗОН ЗАТОПЛЕНИЯ НА ЗАДАННОМ РЕЛЬЕФЕ МЕСТНОСТИ А.В. Хоперсков, С.С. Храпов, А.В. Писарев Волгоградский государственный университет Тел.: (8442) 46-48-94, e-mail: [email protected] Введение Для моделирования динамики поверхностных вод на заданном рельефе местности с учетом широкого спектра физических и метеорологических параметров была разработана локальная геоинформационная система «ГИС НДВ» (рис. 1). Математическая модель основывается на эффективных численных алгоритмах решения нестационарных уравнений Сен-Венана [1–7]. ГИС НДВ использовалась для решения ряда эколого-технических задач Нижнего Поволжья, в частности для определения территорий затопления, изучения режимов оптимального обводнения Волго-Ахтубинской поймы, проведения экспертных оценок функционирования гидротехнических сооружений [8]. Область применимости включает возможность имитации аварийных ситуаций на реках и водохранилищах, включая проблему сезонных наводнений, затоплений, последствий природных и техногенных аварий и катастроф [9]. Построенная геоинформационная система позволяет моделировать плановую динамику затопления прилегающих территорий в зависимости от режима прохождения воды через гидротехнические сооружения и определять наиболее эффективные режимы попуска воды, обеспечивающие сохранение и восстановление водных объектов и природных комплексов заданного региона [10].

Рис. 1. Интерфейс ГИС «НДВ» на примере затопления Волго-Ахтубинской поймы Основные задачи, которые решает серверный программный комплекса ГИС НДВ: • сбор, хранение, обработка географически привязанной информации о состоянии поверхностных вод заданного региона; • унификация данных гидрологической направленности, соблюдение единства методологических подходов, контроль достоверности информации; 80

Труды конференции Телематика’2010

• представление информации в виде атласов, карт, схем, отчетов о гидрологической обстановке; • обработка первичных картографических и фактографических материалов, управление информационными ресурсами, предоставление прав доступа к различным типам информации; • моделирование и прогноз затопления заданного региона в зависимости от характера пропуска воды через гидротехнические сооружения; • определение параметров обводнения в зависимости объема сброса, продолжительности сброса, календаря сброса, гидрологического состояния затапливаемой территории на момент начала сброса; • определение территории и характерных времен затопления, глубины воды на затопленных участках; • определение наиболее оптимальных с экологических позиций условий обводнения поймы. 1. Характеристика серверной и локальной ГИС НДВ Моделирование вышеприведенных ситуаций при помощи ГИС НДВ выявило ряд направлений дальнейшего совершенствования программного комплекса. Одно из приоритетных – создание серверной версии ГИС НДВ с использованием web-технологий. Организация web-доступа к ресурсам геоинформационной системы может: обеспечить удобное совместное пользование результатами расчетов, создать единое хранилище данных, позволить использовать технологии параллельных вычислений (табл. 1). Таблица 1. Сравнительная характеристика локальной и серверной версий ГИС НДВ № 1.

Функциональные возможности Совмещение выполнения повседневной работы и проведения компьютерного эксперимента на персональном компьютере

2.

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

3.

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

4.

Локальная ГИС НДВ частичное, сопряжено с большими трудностями, особенно если компьютер предназначен только для офисной работы (не имеет достаточных вычислительных ресурсов) частичная, так как необходимо переносить объемные данные с одного компьютера на другой, что приводит к потере времени значительные, связанные с покупкой большого количества мощных компьютеров средствами операционной системы

5.

Универсальность применения

решаются только задачи по моделированию динамики зон затопления

6.

Использование параллельных вычислительных технологий

реализовано в рамках одного компьютера

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

Серверная ГИС НДВ должна выполнять следующие основные функции: • обработку входящих запросов; • выполнение информационных и вычислительных задач; • хранение результатов расчетов компьютерных экспериментов; • возврат полученного результата в браузер клиента. Особо стоит выделить, что в серверной версии ГИС НДВ для выполнения расчетных задач будет реализовано разделение модулей, отвечающих за визуализацию данных и проведение расчетов. Расчетный компонент по моделированию динамики зон затопления создается на компилируемом языке программирования (Фортран). Программная часть, отвечающая за визуализацию и предварительную обработку данных, пишется с использованием скриптового языка программирования PHP. Обмен информацией между прикладной программой, выполняемой по запросу пользователя, и HTTP-сервером 81

организуется при помощи CGI. Хранение пространственных и служебных данных выполняется при помощи СУБД MySQL [11]. Для серверной ГИС НДВ разработаны две математические модели, входящие в состав программного комплекса ГИС НДВ и обеспечивающие возможность построения карты затопления в зависимости от формы гидрографа и параметров, влияющих на затопление: • гидродинамическая нестационарная модель движения жидкости, основанная на численном решении уравнений Буссинеска – Сен-Венана (уравнения мелкой воды); • квазистационарная модель зон затопления, основанная на результатах статистической обработки данных гидрологического мониторинга НДВ. 2. Структура программного комплекса ГИС НДВ

Внешняя ГИС

Файловый блок входных данных

Расчетный модуль «ShallowSolwer»

Web-интерфейс программного комплекса «GIS NDV»

Файловый блок настроек проекта

Файловый блок выходных данных

База данных гидрологического мониторинга «NDV_db»

Модуль обработки БД гидрологического мониторинга

Рис. 2. Схема, поясняющая принцип и структуру работы созданного программного комплекса «ГИС НДВ». Стрелками на схеме указаны направления потока данных

Программный комплекс серверной ГИС НДВ включает восемь основных модулей и блоков (рис. 2): • Web-интерфейс программного комплекса «GIS NDV» – обеспечивает управление работой всего программного продукта. Управляет потоками данных, позволяет работать со всеми модулями и блоками программного комплекса ГИС НДВ, обеспечивает взаимную связь между модулями и блоками. • Расчетный модуль «ShallowSolwer» – обеспечивает проведение расчетов посредством программной реализации гидродинамической нестационарной модели движения жидкости. Особенностью данного модуля является возможность проведения параллельных вычислений на многоядерных процессорах, что существенно повышает быстродействие работы программы. • База данных гидрологического мониторинга на заданной местности «NDV_db» – содержит хорошо структурированные данные гидрологического мониторинга исследуемого региона. Позволяет просматривать и редактировать имеющиеся данные, вносить новые данные. • Модуль обработки базы данных «Monitoring» – обеспечивает построение зон затопления по результатам обработки данных гидрологического мониторинга исследуемого региона[12].

82

Труды конференции Телематика’2010

• Файловый блок входных данных – область дискового пространства, предназначенная для хранения картографических данных: векторных карт форматов «SXF», «MAP», «SIT»; матриц абсолютных и относительных высот формата «MTW»; матриц качества формата «MTQ». • Файловый блок настроек проекта – область дискового пространства, предназначенная для хранения настроек проекта (например, данных гидрографа, контрольных точек и дамб): файлов проекта в формате XML и имеющими расширения «RFP», «SPL» и «CPL»; • Файловый блок выходных данных – область дискового пространства, предназначенная для хранения файлов, полученных в процессе моделирования: результирующей матрицы высот в формате «MTW»; матриц качества (файлов состояний) формата «MTQ»; файлов состояний в формате «XML»; файлов форматов «XML» и «DAT-binary», содержащих служебную информацию необходимую для продолжения прерванных расчетов. • Внешняя ГИС. На данный момент ГИС НДВ оптимизирована для работы с ГИС «Карта 2008». Данная геоинформационная система позволяет создавать и редактировать векторные (пользовательские, тематические) карты в форматах «MAP» и «SIT», строить по данным векторных карт матрицы абсолютных и относительных высот в формате «MTW», матрицы качества в формате «MTQ», отображать результирующие файлы формата «MTQ», полученные в процессе проведения расчетов посредством модулей «ShallowSolwer» и «Monitoring», работать с растровыми изображениями, подготавливать и распечатывать презентационные и отчетные материалы. Программные средства, входящие в состав ГИС «Карта 2008», используются программой ГИС НДВ для отображения и обработки картографической информации в процессе проведения расчетов. Заключение Таким образом, использование web-инструментов в сочетании с технологиями высокопроизводительных и распределенных вычислений для решения научно-технических задач по моделированию динамики зон затопления в ГИС НДВ позволит: упростить работу пользователей системы, сократить время проведения компьютерного эксперимента, собрать важные статистические данные в одном месте и обеспечить централизованный доступ к ним. Работа выполнена в рамках следующих проектов (грантов): • «Разработка технического задания «Создание вычислительного центра ВолГУ» (грант № 63-2010а/ВолГУ). • «Геоинформационная система для математического моделирования нелинейной динамики поверхностных вод суши» (грант РФФИ 10-07-97017-р_поволжье_а). Выражаем благодарность ст. преподавателю кафедры Информационных систем и компьютерного моделирования к.ф.-м.н. Кузьмину Н.М. за разработку базы данных гидрологического мониторинга, а также администрации Волгоградской области за оказание финансовой поддержки в рамках молодежного инновационного клуба «Инновариум». Литература 1.

Евстегнеев Н.М. Конечно-объемная TVD-схема для решения 2D эволюционных уравнений мелкой воды. Вычислительные методы и программирование. 2006, т. 7, С. 108–112. 2. Audusse E., Bouchut F., Bristeau M.-O., Klein R., Perthame B. A fast and stable well-balanced schemes with hydrostatic reconstraction for shallow water flows. 2004, SIAM J. Sci. Comp. 25, 2050– 2065. 3. Monaghan J.J. Simulating free surface flows with SPH. 1994, J. Comput. Phys. 110, 399–406. 4. Noelle S., Pankratz N., Puppo G., and Natvig J.R. Well-balanced finite volume schemes of arbitrary order of accuracy for shallow water flows. 2006, J. Comput. Phys. 213, 474–499. 5. Zhou J.G., Causon D.M., Mingham C.J., and Ingram D.M. The Surface Gradient Method for the Treatment of Source Terms in the Shallow-Water Equations. 2001, J. Comput. Phys. 168, 1–25. 6. Куликовский А.Г., Погорелов Н.В., Семенов А.Ю. Математические вопросы численного решения гиперболических систем уравнений. М.: Физматлит, 2001. С. 268–325. 7. Найденов В.И. Нелинейная динамика поверхностных вод суши. М.: Наука, 2004. – 318 с. 8. Хоперсков А.В., Храпов С.С., Еремин М.А., Гусаров Д.В., Плякин А.В., Филиппов О.В., Золотарев Д.В., Кузьмин Н.М. Электронная модель затопления Волго-Ахтубинской поймы при различных гидрографах специального весеннего попуска Волжской ГЭС и водоснабжении рукава Ахтуба на основе технологий геоинформационных систем. Вестник Волгоградского гос. университета. Сер.1.Математика. Физика, вып. 11, 2008, 142. 9. Еремин М.А., Хоперсков А.В. Компьютерная модель прорыва Волжской плотины. Вестник Волгоградского гос. университета. Сер.Физика., вып.10, 2006, 139–142. 10. Горяйнов В.В., Филиппов О.В., Плякин А.В., Золотарев Д.В. Волго-Ахтубинская пойма: особенности гидрографии и водного режима. – Волгоград, Волгоградское научное издательство, 2004. – 112 с. 11. Берлянт А.М. Картография и телекоммуникация (аналитический обзор). М.: 1998. – 76 с. 83

12. Аляутдинов А.Р., Лурье И.К., Осокин С.А. Проектирование и использование локальной инфраструктуры пространственных данных. // XIV Всероссийский форум «Рынок геоинформатики в России. Современное состояние и перспективы развития», CD, /all_site/38332.html. – М.: ГИС-Ассоциация, 2007 (http://www.gisa.ru/38332.html).

СИСТЕМА СПУТНИКОВОГО МОНИТОРИНГА МОБИЛЬНЫХ ОБЪЕКТОВ В.В. Котов, В.Г. Макеев, Р.В. Тихонов, О.Г. Ходяков Воронежский государственный университет E-mail: [email protected], [email protected], [email protected], [email protected] В современном мире все чаще находят своё применение системы спутникового мониторинга. Через некоторое время после появления GPS в США в различных странах начали создаваться проекты аналогичных систем. В России активно развивается ГЛОНАСС. Спутниковый мониторинг применяется теперь не только в военных, но и в мирных целях. Полезное использование включает в себя слежение за автотранспортом, торговыми агентами, оптимизацию логистики, социальные сети. Спутниковые карты, редактируемые общественностью (такие, как OpenStreetMap), часто пополняются новой информацией за счет записи GPS-треков пользователей и нанесения их на карту. Применительно к транспортным средствам такие системы позволяют сократить нецелевые расходы и повысить эффективность использования автопарка. Также системы мониторинга могут применяться для слежения за людьми, что позволяет, например, родителям, учителям и воспитателям всегда быть в курсе, где находится их ребенок, все ли с ним в порядке; руководителям организации – быть в курсе, где находятся их сотрудники в рабочее время. Важными сферами применения является мониторинг сельскохозяйственной техники (точное земледелие), диспетчеризация таксопарков. Проект «TeamPosition» – это система спутникового мониторинга подвижных объектов. Целью проекта является создание базового, универсального средства спутникового мониторинга, которое могло бы в дальнейшем лечь в основу специализированного решения в любой области. Система мониторинга состоит из трех основных частей: • Мобильные GSM/GPS или GSM/ГЛОНАСС терминалы (трекеры). • Сервер системы. • Диспетчерские рабочие места, использующие клиентское приложение. Система работает следующим образом: трекер устанавливается на объект, за которым необходимо производить слежение, после чего определяет координаты объекта и передает на сервер системы с определенной периодичностью. Пользователь системы получает удобный доступ к обработанным данным, как в графической форме, с использованием картографии, так и в текстовой – на основе накапливаемых данных возможно формирование различных видов отчетов. Общая схема работы системы (вариант для мониторинга транспортных средств) приведена на рис. 1 [1].

Рис. 1. Схема работы системы мониторинга

84

Труды конференции Телематика’2010

Большинство систем, присутствующих на рынке, используют GPS или ГЛОНАСС трекеры в различных вариантах исполнения. Помимо функции передачи координат, некоторые, более дорогие, версии подобных устройств обеспечивают поддержку аналоговых и цифровых входов и выходов для взаимодействия с бортовыми системами транспортных средств. Главный минус использования GPS/ГЛОНАСС трекера – высокая стоимость. Устройство, основанное на GPS, имеет среднюю стоимость порядка 15000 р., аналог с ГЛОНАСС стоит более 20000 р. Предлагаемое решение этой проблемы – использование связки, включающей в себя мобильный телефон и Bluetooth GPS модуль, общей стоимостью менее 6000 р. Это позволяет существенно снизить стоимость внедрения системы мониторинга. Кроме того, это дает возможность внести в систему дополнительную функциональность для ряда задач, т.к. с помощью мобильного телефона (в отличие от GPS/ГЛОНАСС трекера) возможен двусторонний обмен данными с мобильными объектами. Например, возможно применение в следующих отраслях: • Агротехническая отрасль: сведения о дневном плане и ходе его выполнения. • Работа таксопарков: сведения о поступивших заказах, их распределение между водителями, информация о текущем статусе водителя и ходе выполнения заказа. Заказ может передаваться на исполнение географически ближайшему автомобилю. • Координация сотрудников (например, торговые представители, экспедиторы): список заданий (встреч) с привязкой к координатам, обновляющийся в реальном времени, возможность отправки результатов выполнения, оптимизация и контроль маршрутов, графиков движения. • Социальные сети: мобильное приложение, позволяющее видеть текущее положение пользователей сети в реальном времени, организация чата. • Возможность реализации приложений дополненной реальности. На рынке представлен ряд систем мониторинга, являющихся продуктами крупных компаний, таких как «М2М-телематика», «АвтоГРАФ». Продукты подобного рода имеют жесткую структуру, ориентированную на универсальность. Отраслевые решения, построенные на основе универсальных, не предоставляют требуемый уровень специализации для конкретной предметной области, так как отсутствие двустороннего взаимодействия накладывает существенные ограничения. При этом технологии, применяемые в разработке, зачастую являются устаревшими из-за длительного срока развития систем. В существующих системах приложение диспетчера является сложным в настройке и использовании. Более простые системы мониторинга не предоставляют пользователю нужный объем информации и не соответствуют нуждам организаций. Из этого можно поставить требования к приложению диспетчера системы: • Приложение должно быть удобным, простым и, при этом, удовлетворять функциональным требованиям. • Приложение должно базироваться на передовых технологиях разработки программного обеспечения. • Предоставление системы как веб-сервиса. • Возможен договор о продаже коробочной версии продукта по требованию заказчика. • Доработка системы по договоренности с заказчиком. Задача проекта «TeamPosition» состоит в создании системы спутникового мониторинга, позволяющей предоставлять актуальную информацию о текущем состоянии объектов слежения, накапливать, систематизировать и анализировать информацию об объектах слежения в течение периода использования системы, осуществлять двустороннюю связь с объектами слежения. Система должна работать с разными моделями мобильных телефонов, помимо этого должна быть возможность интеграции в систему различных GPS/ГЛОНАСС трекеров. В качестве языка разработки, как серверной части, так и мобильного клиента используется язык Java, что обеспечивает кроссплатформенность решения. Сервер приложения использует СУБД PostgreSQL 8.4, которое является одной из лучших бесплатных СУБД enterprise-уровня. Кроме того, для PostgreSQL существует расширение PostGIS, существенно упрощающее работу с географическими данными. Взаимодействие с базой данных реализовано с применением ORM Hibernate Framework [2,3]. Для автоматизации ряда задач, таких как безопасность, разграничение прав, инстанцирование объектов, управление доступом к СУБД на сервере используется Spring Framework 3.0 [4]. В качестве методологии разработки клиентского приложения выбрана методология Rich Internet Application (RIA). Преимуществами данного подхода являются низкие системные требования, кроссплатформенность, отсутствие необходимости локальной установки приложения, безопасность. Тонкий клиент в RIA переносит все задачи обработки информации на сервер, а сам используется лишь для отображения статической информации и результатов обработки. Средством реализации вебприложения является технология Google Web Toolkit компании Google, позволяющая веб-разработчикам создавать RIA на основе Java. Компилятор GWT переводит код Java-приложения в соответствующий браузеру JavaScript и HTML. Для реализации пользовательского интерфейса применяется технология Ext GWT [5] от компании ExtJS, существенно упрощающая разработку. Ext GWT является расширением технологии Java фреймворка GWT. Для представления картографической информации в приложении используются API Google Maps, OpenStreetMap, Yandex Maps. Для разработки приложения используется IDE NetBeans 6.8. В разработке мобильного приложения применяется набор средств Sun Java Wireless Toolkit, а также эмуляторы мобильных телефонов от компании Nokia. 85

Для проектирования базы данных используется Toad Data Modeler. Так же была применена система контроля версий SVN, система сборки проекта Maven. На данный момент достигнуты следующие результаты: • Разработано программное обеспечение, позволяющее получать и накапливать данные о перемещениях объектов в пространстве. • Разработано программное обеспечение, позволяющее отображать информацию о текущем состоянии объектов слежения в текстовом и графическом (с помощью картографии) видах. Также разработан инструмент, позволяющий отображать накопленную за период времени информацию об объектах слежения в графическом виде (траектории движения объектов на карте). Работа с программным обеспечением осуществляется с любого ПК, имеющего подключение к сети Интернет, с помощью браузера. • Разработано программное обеспечение для мобильного телефона, позволяющее осуществлять обмен данными с серверной частью системы. Следует отметить следующие особенности системы: • Оптимизация трафика между веб-клиентом и сервером, а также между мобильным клиентом и сервером. При первом обращении к серверу клиент получает актуальную информацию о текущем состоянии пользователей группы. Время обращения клиента к серверу сохраняется в веб-сессии. При последующих запросах клиент получает данные об изменениях, произошедших в системе после предыдущего обращения. Данное решение позволяет существенно сократить объем трафика системы, что является критичным для GPRS-соединения. • Возможность удаленной конфигурации работы клиентов с помощью изменения набора параметров на стороне сервера. Это позволяет гибко управлять уровнем нагрузки на сервер, что впоследствии будет положено в основу автоматизированной системы управления нагрузкой (оценка и прогнозирование уровня нагрузки на основе набора факторов, регулирование нагрузки с помощью редактирования параметров). К изменяемым параметрам системы относятся: интервалы времени между опросами сервера, максимальное расстояние между двумя переданными позициями (от этого параметра зависит частота передачи данных о позиции объекта на сервер). • Зависимость частоты передачи географических данных от скорости объекта наблюдения. При увеличении скорости данные передаются чаще, если же объект стоит на месте, можно передавать информацию о местоположении существенно реже. • Для построения отчетов, основанных на пройденном расстоянии и траектории мобильных объектов, применяется интерполяция траектории сплайнами Акимы. Это позволяет увеличить точность по сравнению с линейной интерполяцией. GPS-трекер посылает данные о местоположении на сервер с определенной периодичностью. Данные могут поступать на сервер с некоторым запозданием из-за проблем со связью. Помимо этого, для построения анимации перемещения объекта по траектории необходимо определять местоположение объекта в промежуточные моменты времени, например, через каждые 3 с. Возникает проблема интерполяции пути. Объект перемещается в двумерном пространстве, поэтому необходимо производить независимую интерполяцию по координатам X и Y. Было принято решение применить сплайн-интерполяцию, ввиду ее малой трудоемкости и достаточной степени точности. Применяя линейную интерполяцию, мы получили бы движение объекта по отрезку между точками отчета GPSтрекера, точность линейной интерполяции не высока. Недостатком кубических сплайнов является то, что они склонны осциллировать в окрестностях точки, существенно отличающейся от своих соседей. Для интерполяции были использованы сплайны Акимы. Сплайн Акимы − это особый вид сплайна, устойчивый к выбросам. Сплайн Акимы в меньшей мере подвержен влиянию выбросов на отрезках, граничащих с выбросом, практически отсутствуют признаки осцилляции. Важным свойством сплайна Акимы является его локальность – значения функции на отрезке [xi , xi+1 ] зависят только от fi-2 , fi-1 , fi , fi+1 , fi+2 , fi+3 . Вторым свойством, которое следует принимать во внимание, является нелинейность интерполяции сплайнами Акимы – результат интерполяции суммы двух функций не равен сумме интерполяционных схем, построенных на основе отдельных функций. Для построения сплайна Акимы требуется не менее 5 точек. Во внутренней области (т.е. между x2 и xN-3 при нумерации точек от 0 до N1) погрешность интерполяции имеет порядок O(h2). По сути, сплайн Акимы есть сглаживание функции. Вид исходной и интерполированной траектории движения объекта можно видеть на рис. 2. В качестве GPS-трекера в системе в настоящий момент используется мобильный телефон с GPSмодулем. Java-приложение, устанавливаемое на телефон, для определения текущего положения может использовать как внешний GPS-модуль, подключаемый к мобильному телефону посредством Bluetooth, так и встроенный. Приложение разработано на Java2ME, что обеспечивает его кроссплатформенность и делает совместимым с широким рядом моделей мобильных телефонов, смартфонов и коммуникаторов. Для отображения собственного положения и позиций других участников группы мобильный клиент использует картографические сервисы компаний Google, Yandex, OpenStreetMap. Взаимодействие мобильного клиента с серверной частью реализовано на основе REST (REpresentational State Transfer) веб-сервиса [6]. В общем случае REST является очень простым интерфейсом управления информацией без использования дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждый URL, в свою очередь, имеет строго заданный формат. Веб-сервис в ответ на HTTP-запрос возвращает сериализованные данные в формате XML. 86

Труды конференции Телематика’2010

Рис. 2. Вид исходной (слева) и интерполированной (справа) траектории Разработанная система является легко расширяемой. Интеграция специализированного устройства мониторинга сводится к добавлению одного класса-шлюза. В данный момент на основе системы мониторинга разрабатывается система автоматизации работы диспетчерской службы таксопарка. В мобильном приложении водителя и серверной части, обеспечивающей взаимодействие с мобильным клиентом, применяются разработанные модули системы мониторинга. Дальнейшими планами развития проекта являются: • доработка некоторых модулей, расширение функциональности; • интеграция со специализированными устройствами слежения; • формирование системы отчетности по показателям (расход топлива, пробег и т.д.); • развитие функциональности для различных областей специализации системы (такси, социальные сети, сельское хозяйство); • внедрение системы в работу предприятий и ее коммерческое использование. Литература 1. Global Positioning. Technologies and Performance / N. Samama – John Wiley & Sons Inc, 2008 – 440 с. 2. Developing with Ext GWT Enterprise RIA Development / Grant Slender – Apress, 2009 – 140 с. 3. Spring Persistence with Hibernate / Ahmad Reza Seddighi - Packt Publishing, 2009 – 420 c. 4. Hibernate in Action / Bauer, King — TheServerSide.com, 2004 – 400 c. 5. Spring in Action 2nd Edition / Craig Walls, Ryan Breidenbach - MANNING, 2007 – 670 c. 6. Архитектура корпоративных программных приложений / М. Фаулер – Издательский дом "Вильямс", 2006. – 544 с.

РАЗРАБОТКА WEB-ПРИЛОЖЕНИЙ НА ОСНОВЕ ТЕХНОЛОГИИ OntoBox/Libretto А.А. Хенкина, М.А. Кохо Иркутский государственный университет E-mail: [email protected], [email protected] Введение В данной работе рассматриваются аспекты применения технологии OntoBox/Libretto [1] к построению web-приложений научно-образовательного характера. В основе технологии OntoBox/Libretto лежит идея применения «интеллектуальных» средств математической логики к решению массовых задач построения информационных ресурсов. Интеллектуализация мирового информационного пространства является сегодня одним из магистральных направлений развития, целью которого является построение в Интернете продвинутых сервисов, способных взять на себя решение ряда задач, которые сегодня приходится решать пользователю. Этой проблематике посвящен ряд крупных проектов, включая проект Т. Бернерса-Ли «Семантический веб» [2]. Как правило, такие проекты основаны на логических средствах. К сожалению, продвижение мощных и выразительных средств математической логики связано с рядом трудностей, среди которых отметим две: • «Элитность» логических средств, их недоступность для массового пользователя. • Высокая алгоритмическая сложность логических средств, их неэффективность. 87

Проект OntoBox/Libretto сфокусирован на решении этих двух проблем. Он основан на специальных дескриптивных логиках [3]. Эти логики, во-первых, позволяют «инкапсулировать» логические механизмы, спрятать их от массового пользователя и, тем самым, снять барьер непонимания. Разработан специальный язык запросов Libretto [4], который превращает работу в логической среде в хорошо всем знакомый механизм построения объектных моделей в виде онтологий специального вида. Во-вторых, данные логики обладают очень эффективной процедурной семантикой, что делает их конкурентоспособными даже с точки зрения таких структур, как реляционные базы данных. На основе технологии OntoBox/Libretto нами были построены два образовательных информационных ресурса. Эти ресурсы имеют разную природу и строятся совершенно по-разному. Однако нами показано, что для обоих проектов технология OntoBox/Libretto оказалась удобной и эффективной. Первый проект представляет собой базу знаний по флоре Прибайкалья. В рамках второго проекта реализована технология создания тематических научно-образовательных форумов, которая затем была применена для модернизации известного образовательного ресурса – консультации по математическому анализу. Рассмотрим эти проекты и использование технологии OntoBox/Libretto более подробно. База знаний флоры Байкальского региона Флора Байкальского региона насчитывает 2834 вида растений. Частичная и не полностью систематизированная информация об этих видах распределена по различным монографиям и статьям. В настоящее время отсутствует полное регулярное структурированное описание растений, что создает определенные трудности при поиске необходимой информации. В рамках деятельности научнообразовательного центра Байкал накоплена база данных с информаций о более чем 2300 видов растений и разработана система для представлений знаний в форме онтологий, которая позволяет эффективно описывать классификации видов. Цель и задачи. Целью работы являлось создание web-ориентированной базы знаний флоры Байкальского региона с использованием онтологий как формы представления знаний. Для достижения данной цели были решены следующие задачи: • разработка объектной модели таксономии растений Байкальского региона; • проектирование и разработка web-приложения для ввода и отображения данных. Актуальность. Регулярным образом представленная информация о флоре Байкальской Сибири может сыграть важную роль, как для поддержки научных исследований уникальной экосистемы озера, так и в образовательном процессе. Реализация проекта даст возможность доступа к информации о местных растениях школьникам, студентам и преподавателям. С точки зрения организации данных представляет интерес использование онтологий для представления иерархических структур данных и разработки web-приложений. Онтология разработана для представления знаний о растениях, содержит множество сложных связей между объектами, а также реализует типичный пример иерархической структуры – таксономию (классификацию) растений. Принципы проектирования и реализации системы. Реляционная модель не является оптимальной для работы с иерархическими структурами данных, поскольку эти данные не представимы естественным образом в табличном виде. Также в реляционной модели существуют определенные трудности с множественным наследованием, и практически невозможно избежать избыточности информации. В данной работе используется метод представления данных в формате онтологий на основе объектной модели. Объектная модель системы позволяет естественным образом представить древовидные структуры данных в виде иерархии классов и объектов. При создании web-приложения были использованы следующие технологии: • онтологическая система хранения данных и знаний OntoBox; • язык запросов Libretto, ориентированный на управление данными и знаниями на уровне объектных описаний; • объектно-ориентированный язык Java; • открытый web-фреймворк Wicket. На первом этапе разработки были изучены основные характеристики растений и системы классификаций растений по группам. На базе проведенных исследований создана онтология флоры Байкальского региона, содержащая набор классов, составляющих таксономию растений, а также классы, хранящие информацию о свойствах растений (категории охраны, распространение, фотографии и другие характеристики). Для хранения данных использована система хранения и обработки знаний OntoBox [1, 4, 5]. В системе реализован объектно-ориентированный подход для хранения и представления онтологий, что значительно упрощает процесс проектирования и разработки базы знаний предметной области. Для ввода описаний структуры онтологии и ввода данных использовалась система Мета2 [6]. На данный момент в онтологии растений Байкальского региона представлена информация о 2330 растениях, онтология содержит 7827 объектов, 37 классов, 61 свойство, 29 из которых являются О-свойствами, т.е. свойствами, которые связывают объекты класса с объектами другого фиксированного класса. На втором этапе разработки спроектирован и реализован пакет Java-классов, соответствующих классам онтологии, и определены методы получения данных из системы OntoBox. Для получения информации о свойствах и связях между сущностями онтологии используется язык запросов Libretto [1, 4]. 88

Труды конференции Телематика’2010

Рассмотрим Libretto-описание класса Taxon, с помощью которого организована классификационная иерархия растений в онтологии. class Taxon { nameAuthor[,1] {xsd:string}, # имя автора biblio {xsd:string}, # библиографические данные super[,1] {Taxon}, # класс-родитель latinName[1,1] {xsd:string}, # латинское название sinonim {Taxon}, # синонимы rusName[1,1] {xsd:string} # русское название }; В определении класса описаны его свойства: кардинальность и тип данных. Объекты класса Taxon образуют древовидную структуру, отражающую связи подвидов, видов, родов, семейств и других уровней таксономии растений. Для получения полного пути от элемента до корня иерархии используется рекурсивная функция, написанная на языке Libretto: function getParents($Child) # функция получения таксономии для $Parent := $Child/super # объекта $Child $latinName := $Child/latinName if ($Parent) ($latinName, getParents($Parent)) else ($latinName); getParents(&Myosotis_baicalensis); # вызов функции для объекта Результатом выполнения функции является таксономия вида Myosotis baicalensis (Незабудка байкальская), отражающая его положение в классификационной системе. Приведенный пример демонстрирует преимущества обработки иерархических структур в сравнении с реляционным подходом, и в целом выразительность и эффективность описания данных в системе OntoBox с помощью языка запросов Libretto. На третьем этапе, на основе web-фреймворка Apache Wicket (http://wicket.apache.org), разработаны web-интерфейсы пользователя и администратора базы знаний. Wicket является открытой компонентноориентированной средой web-разработки на основе традиционных Java-объектов (plain old Java object – POJO). Использование Wicket позволило, разделить роли разработчиков и дизайнеров, в частности отказаться от использования JSP на уровне представления архитектуры модель-представлениеконтроллер (Model-View-Controller, MVC). Интерфейс пользователя позволяет осуществлять доступ к информации о растениях Байкальского региона, в частности, реализовано несколько систем поиска, с помощью которых обеспечивается эффективная работа с базой знаний. Административный интерфейс позволяет выполнять работы по модификации данных в онтологической базе: добавление новых сущностей в онтологию, редактирование и удаление сущностей из онтологии. Результаты: • Реализовано web-приложение, которое будет использовано для поддержки учебного процесса и научных исследований уникальной экосистемы озера Байкал (http://flora.baikal.ru). • Апробированы технологии построения web-приложений на базе системы OntoBox и языка запросов Libretto. Онтофорум как часть системы открытого образования Системы открытого образования (ОО) в Интернете постепенно приобретают все большую и большую популярность как формат обучения. Одним из основных инструментов общения между преподавателем и студентами в Интернете является тематический форум, на котором обсуждаются различные вопросы изучаемой предметной области. С накоплением информации на форуме, поиск необходимых данных становится затруднен из-за недостатков систем поиска. Цель и задачи. Целью данной работы является создание онтофорума с использованием онтологий как формы представления знаний, являющегося развитием концепции веб-форума и направленного на использование в системах открытого образования. Онтофорум – тематический форум со следующими дополнительными свойствами: • Обсуждаемая предметная область формально описывается в виде онтологии или набора онтологий, объекты которых используются как метаданные для разметки диалогов на форуме. • Онтофорум имеет специализированный веб-интерфейс модератора/преподавателя, позволяющий классифицировать («размечать») материалы обсуждений на форуме. • Онтофорум допускает реализацию «интеллектуальных» сервисов, которые в автоматическом режиме используют материалы вместе с онтологической разметкой (пример: информационносправочная система, автоматически генерируемая по материалам обсуждений на форуме). Для достижения данной цели были решены следующие задачи: • Создание объектной модели, описывающей структуру онтофорума. 89

• Реализация модели в формате онтологии на базе OntoBox с использованием языка запросов Libretto. • Создание веб-интерфейса для связывания объектов онтофорума с объектами из онтологии, описывающей предметную область. • Разработка веб-интерфейса для описания предметной области. Актуальность. В Интернете широкую популярность приобретает адаптированная для конечного пользователя форма классификации материалов – тегирование информации. Под тегированием информации подразумевается присвоение метки, или другими словами тега, определенному Интернетресурсу – фотографии, сообщению или ссылке на какой-либо сайт. Теги позволяют в некоторой степени понять, что скрывает размеченная информация. Однако системы тегирования, предназначенные упорядочивать информацию и облегчать доступ к ней, имеют несколько минусов, затрудняющие ее поиск: • некорректное написание тегов; • синонимия тегов; • полисемия и омонимия тегов. Описанные выше трудности поиска объединяет одна общая причина – недостаток метаинформации о тегах. Популярные системы тегирования не предоставляют возможность указать конкретный смысл тега, по которому производился бы поиск. В зависимости от количества значений, которыми обладает тег, значительно варьируется количество иррелевантной информации в результатах поиска. Например, запросив данные с тегом OSX, маловероятно, что пользователь получит что-нибудь, не касающееся операционных систем компании Apple. Однако в случае поиска по тегу language, который может означать как человеческий язык, так и компьютерный, пользователь столкнется с некоторым количеством информации, не имеющей отношения к цели его поиска. Принципы проектирования и реализации системы. Онтофорум состоит из тематического форума, предоставляющего площадку для дискуссий, и системы разметки данных тематического форума. Данные онтофорума хранятся в формате онтологии и разделены на две ключевые онтологии: • онтология форума, которая содержит основные компоненты тематического форума (сообщения, темы и т.д.); • онтология знаний, которая содержит формальное описание обсуждаемой предметной области. Основной задачей онтологии знаний является предоставление метаданных для разметки сообщений онтофорума. Метаданные представлены в виде тегов и используются для управления, упорядочивания и поиска информации, хранящейся в онтологии форума. Преподаватель/модератор онтофорума, тегируя объектами онтологии знаний сообщения, включает последние в контекст предметной области. Таким образом, он делает их доступными для автоматических («интеллектуальных») обработчиков, оперирующих контентом онтофорума. Операция присваивания тегов достаточно проста, что позволяет привлекать для тегирования модераторов без специальной подготовки. При создании онтофорума были использованы следующие технологии: • онтологическая система хранения данных и знаний OntoBox; • язык запросов Libretto, ориентированный на управление данными и знаниями на уровне объектных описаний; • объектно-ориентированный язык Java; • технология JSP; • открытый JavaScript фреймворк Prototype. Ниже приведены Libretto-описания класса Tag, экземпляры которого используются как теги, и класса Tagged, экземпляры которого могут быть тегированы: class Tag { name[1, 1] {xsd:string}, # имя тега description[0, 1] {xsd:string}, # описание тега subTag {Tag}, # дочерние теги relatedTag {Tag} # родственные теги }; class Tagged { tag {Tag} # принадлежащие объекту теги }; Тег обладает именем, выражающим его суть, может иметь описание, дочерние или родственные теги. При помощи дочерних тегов можно организовать иерархию, и таким образом объединять теги в смысловые группы. При помощи родственных тегов можно устанавливать связи между объектами, описывающими родственные понятия. Несмотря на простоту класса Tagged, он имеет большое значение, Благодаря реализованной в Libretto поддержке множественного наследования, любому объекту предметной области могут сопоставляться теги. Например, достаточно указать Tagged как суперкласс у класса Thread, выполнив следующий запрос на Libretto: class Thread {Tagged};

90

Труды конференции Телематика’2010

После этого у всех объектов класса Thread появляется свойство tag, в котором будут храниться присвоенные теги. Таким образом, открываются широкие возможности по классификации уже существующих онтологий. Следующий запрос Libretto находит все сообщения, касающиеся программного обеспечения фирмы Apple и имеющего отношение к музыке: Tag [name = ‘Apple’]/subtag [name = ‘software’]/subtag [related/name = ‘music’]/~tag; В квадратных скобках задаются условия на объект. При помощи символа ‘/’ мы обращаемся к свойствам объекта. Символ ‘~’ обозначает инверсное свойство. Например, если объект &iTunes является значением свойства tag объекта &msg, то запрос &iTunes/~tag, вернет объект &msg. Таким образом, в нашем примере мы не перебирали множество сообщений, а нашли сначала удовлетворяющие условиям объекты онтологии и затем сообщения, тегированные этими объектами.

Рис 1. Интерфейс разметки диалогов форума На рис. 1 иллюстрируется процесс метаописания («тегирования») форума по математическому анализу. В левой части интерфейса, изображенного на рис. 1, представлено дерево изучаемых областей математического анализа (это часть онтологии «знаний о матанализе»). В правом окне интерфейса изображена структура темы онтофорума с присвоенными ей тегами. Теги указывают, что данная тема относится к областям линейных дифференциальных уравнений первого порядка и нахождения частных производных, и что обладает меньшей трудностью. Используя присвоенные метаданные к темам форума, «интеллектуальные» обработчики информации в дальнейшем реорганизуют накопленные материалы в компактную информационно-справочную систему. Результаты: • создана онтология форума из накопленных материалов веб-форума по задачам математического анализа, который функционирует с 2003 года и поддерживается преподавателями ИМЭИ ИГУ; • создана онтология знаний из имеющейся онтологии, объединяющей области изучения математического анализа в иерархическую структуру и описывающей такие понятия как сложность обсуждаемой темы форума и ее полезность; • разработан онтофорум, включающий в себя созданные онтологии и веб-интерфейсы для управления ими. Заключение В данной работе рассмотрены задачи построения научно-образовательных информационных ресурсов с помощью технологии OntoBox/Libretto. Результаты работы показывают, что данная технология является удобной для решения подобного рода задач. Следует также отметить, что в 91

процессе реализации проектов авторами были выработаны рекомендации по улучшению самой технологии. Литература 1. Технология обработки данных и знаний OntoBox // http://ontobox.org. 2. Semantic Web // http://www.w3.org/2001/sw/. 3. Малых А.А, Манцивода А.В, Ульянов В.С. Логические архитектуры и объектно-ориентированный подход // Вестник НГУ. Серия: Математика, механика, информатика, 2009, Т.9, вып. 3. – С. 64–85. 4. Malykh, A., Mantsivoda, A. A Query Language for Logic Architectures // Lecture Notes in Computer Science. – Springer-Verlag, 2010. – V. 5947 – P. 294–305. 5. А.В. Манцивода, А.А. Малых. OntoBox: ядро системы «Мета-2»// Труды Всероссийской научнометодической конференции «Телематика'2008». – СПб., 2008. – С.120–121. 6. Малых А.А., Манцивода А.В. МЕТА-2: поддержка онтологий и образовательные системы // Труды всерос. конф. «Телематика’2005».– СПб., 2005. – С. 232–233.

АВТОМАТИЗАЦИЯ ПРОЦЕССА ОЦЕНКИ ИСПОЛНИТЕЛЬСКОЙ ДЕЯТЕЛЬНОСТИ ДЛЯ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА Е.Д. Пфайф, А.М. Гудов Кемеровский государственный университет E-mail: [email protected] Для любого образовательного учреждения остро стоит вопрос о дифференцированной оценке эффективности выполнения административными работниками своих должностных функций. Если задачи, связанные с оценкой эффективности труда преподавателей, уже как-то проработаны, то система измерений и оценок исполнительских функций пока недостаточно разработана [1]. В настоящее время нет достаточно адекватной оценки реализации управленческих решений, включая оценку деятельности персонала управления. Решение вопроса осложняется в том случае, когда такую оценку необходимо максимально «автоматизировать» для того, чтобы эффективно использовать статистические данные, получаемые с помощью какой-нибудь информационной системы управления или, например, системы электронного документооборота (СЭД). В данной работе предлагается математическая модель автоматизированной системы оценки исполнительской деятельности, специально разработанная для использования в подсистеме учета поручений СЭД, внедренной в Кемеровском государственном университете. 1. Модель исполнительской деятельности Исполнительская деятельность представляет собой процесс, направленный на получение результата при выполнении конкретного поручения исполнителем в ходе реализации управленческих решений в организации. Требования к оценке со стороны исполнителя и руководителя можно сформулировать так [2]: • прозрачность оценки, как со стороны руководителя, так и исполнителя; • возможность диалога и «обратной связи между ними»; • оперативность и достоверность результатов оценки; • влияние на конечные результаты деятельности организации; • поощрение и стимулирование сотрудника на повышение эффективности исполнительской деятельности; • возможность оценивания в разрезе одного или множества поручений на любом интервале времени; • инвариантность к типу и виду собственности организации; • универсальность по отношению к особенностям, как руководителя, так и исполнителя; • понятность показателей оценки, возможность оценки их качества. В основе предлагаемой модели лежит модель оценки исполнительской деятельности метода РОДАР [3], в которой исходя из требований, предъявленных к оценке, первоначальную декомпозицию исполнительской деятельности предлагается проводить с использованием формальной модели структуры социально-экономической системы, где в качестве субъекта деятельности выступает исполнитель. Под исполнителем здесь понимается лицо, принимающее решение из числа работников, составляющих персонал аппарата управления организации по следующим категориям: высшее звено руководителей, среднее звено руководителей, низшее звено руководителей, специалисты. В качестве средств деятельности рассматриваются профессиональные знания, опыт, навыки, информация, компьютерная и иная техника, различные носители информации и оборудование рабочего места. Технологию управления организацией можно представить в виде методов планирования, организации контроля, анализа труда, материального и морального стимулирования. 92

Труды конференции Телематика’2010

Окружающую среду исполнителя представляют коллеги, работники других подразделений, составляющих коммуникационное, информационное, психологическое пространство жизнедеятельности организации [2]. С учетом вышеизложенного, исполнительская деятельность с использованием формальной модели структуры представима в виде набора элементов: технология выполнения поручения, персонал аппарата управления, средства деятельности, исполнитель. Исходя из того, что умственная нагрузка любого работника адекватна уровню сложности производственных поручений, которые он при этом решает, дальнейшую декомпозицию исполнительской деятельности предлагается производить по элементу исполнитель. В качестве объекта исполнительской деятельности можно принять поручение. Понятие «поручение» выступает как единица контроля исполнения документированного решения – некоторое действие, имеющее одного исполнителя и определенный срок. Поручение может декомпозироваться на части, при этом каждое из получившихся поручений будет иметь единственного исполнителя. Поручение, которое не декомпозируется, будем называть самостоятельным, а в противном случае агрегированным. Заметим, что для любой СЭД (имеется в виду системы, широко представленные на российском рынке) реализации поручения может иметь следующие атрибуты: 1. Оценка по факту выполнения: заданное время выполнения поручения T и реальное время выполнения поручения t. 2. Источник инициирования поручения In (рекомендованные значения в [1]: In=1 – вышестоящие организации; In=0.8 – потребители конечного продукта; In=0.5 – структурные подразделения организации; In=0.3 – подведомственные подразделения организации). 3. Уровень агрегированности поручения A, т.е. наличие зависимых поручений, на которые будет декомпозироваться данное поручение. 4. Тип Type (наименование) документа, к которому прикреплено поручение: • высший уровень иерархии a1 (0,4 – входящие документы, 0,3 – исходящие документы, 0,3 – внутренние документы); • средний уровень иерархии а2 (0,4 – вышестоящие организации, 0,3 – нижестоящие организации, 0,3 – другие); • низший уровень иерархии а3 (0,4 – финансово-бухгалтерские документы, 0,4 – организационнораспорядительные документы, 0,2 – коммерческие договора и прочее). 5. Уровень иерархии исполнителя для каждого исходного или декомпозированного поручения. Для этих характеристик определим формальные связи и получим параметры элемента поручение. Исходя из принципов декомпозиции, количественная оценка каждого из параметров должна лежать на отрезке [0; 1]. Для получения итоговой оценки исполнительской деятельности определены следующие параметры: точность в сроках выполнения поручения, уровень агрегированности поручения, параметры исполнителя, приоритет. 1. Точность в сроках выполнения поручения (временные потери организации):

T −t ⎧1 ⎪ 2 (1 + T ), если поручение выполнено раньше срока ⎪⎪ 1 t −T ), если поручение выполнено раньше срока , Acc = ⎨ (1 − 2 t ⎪ ⎪ 1 (1 + 1 ), если поручение не выполнено ⎪⎩ 2 T где время t рассчитывается двумя способами: 1) если поручения самостоятельное, то в качестве t берется время его выполнения; 2) в случае агрегированного поручения – промежуток времени от момента создания данного поручения и до момента окончания самого последнего зависимого (вложенного) поручения. Множитель ½ выступает в качестве медианы оценки параметра. Значения T-t и t-T представляют собой количество дней, показывающих, на сколько раньше или позже было выполнено поручение. Чем больше эта разница, тем больше (или меньше в случае задержки срока выполнения) оценка параметра. Если поручение не выполнено, то с помощью данной оценки подсчитывается ущерб, который был нанесен организации. 2. Уровень инновационности поручения (подпараметр):

I = Type * L , где Type=а1*(а2+а3), в зависимости от типа документа определяются коэффициенты а1, а2, а3; L – коэффициент инновационности (величина которого зависит от количества выполненных подобных поручений) определен следующим образом: • L=1 – поручение нестандартное (не имеет аналогов, т.е. исполняется впервые); • L=0.8 – поручение нестандартное (не имеет аналогов, но исполняется уже несколько раз); • L=0.5 – поручение имеет неполные аналоги (прототипы) и требует некоторой творческой деятельности; • L=0.2 – поручение периодически повторяется (типовое). 93

Исходя из этих требований, получим методом наименьших квадратов непрерывную зависимость коэффициента L от количества поручений:

L=

1 + 0,04 , 0,0574 + 0,9861* X

где X – количество поручений. 3. Уровень агрегированности поручения:

D , K

A=

где K – количество уровней декомпозиции поручения, а D – данный уровень декомпозиции. Уровни нумеруются снизу вверх, если поручение не выполнено, и сверху вниз, если поручение выполнено. Нужно заметить, что в случае выполнения поручения наибольшую оценку получает непосредственный исполнитель поручения. Если поручение не выполнено, то наибольшую ответственность несет руководитель – он получит высокую штрафную оценку. 4. Параметр исполнителя (Rs) представляет собой величину:

R s = 0 ,1 ⋅ ( K v + S + H +

Zt ), Z

где смысл входящих параметров объясняется ниже, а коэффициент 0,1 выбран из эмпирических соображений. Данные об образовании исполнителя, его стаже и возрасте учитываются путем расчета коэффициента профессиональной перспективности по формуле [4]:

Kv = 0.01 × O × (1 +

St V + ), 4 18

где О – оценка уровня образования; St – стаж работы по специальности; V – возраст; коэффициенты ¼ и 1/18 взяты в соответствии с рекомендациями НИИ труда; Оценка параметра «Стабильности выполнения поручений» производится по следующей формуле:

1 S= N

N

∑ Acc

i

i =1

,

где N – количество поручений, выполненных данным сотрудником. Оценка параметра «Напряженность труда» производится по следующей формуле:

H=

Tr Ts + Tr

,

где Ts – среднее время выполнения подобных поручений в организации и вычисляется по формуле: n

Ts =

1 ∑T i n i =1

,

здесь n – общее количество поручений данного типа на данном промежутке времени, Ti – время выполнения i-ого поручения. Tr – среднее время выполнения поручений данного типа этим сотрудником, рассчитывается по формуле:

1 Tr = N

N

∑T j =1

j

Оценка параметра «Загруженность» производится по формуле:

1 Z= N 94

N

∑ In . i =1

i

Труды конференции Телематика’2010

Оценка параметра «Загруженность текущая» производится по формуле:

1 Zt = Nt

Nt

∑ In

i , i =1 где Nt – количество поручений сотрудника в текущий момент. 5. Приоритет поручения К=I*In завит от уровня инновационности и источника инициирования. Таким образом, общую оценку исполнения поручения можно определить как:

W = q1 A + q2 Acc+ q3 Rs+ q4 K , где

4

∑ qi = 1 весовые коэффициенты, которые можно задать эмпирически или рассчитать с помощью 1

какого либо подхода. Поскольку задача подбора коэффициентов представляет по своей сути задачу аппроксимации линейной многомерной вещественной функции, то в нашем случае для вычисления коэффициентов qi применяется простая нейронная сеть – однослойный персептрон с тождественной функцией активности. Используется обучение с учителем на основе правила Видроу-Хоффа с нормой обучения равной 0,1. Данными для обучения сети были оценки параметров: точность в сроках выполнения, приоритет, параметры исполнителя, уровень агрегированности и соответствующие им оценки сотрудников, рассчитанные по РОДАР [3]. Полученные коэффициенты представлены в таблице 1. Таблица 1. Коэффициенты оценки для выполненного и невыполненного поручения Коэффициент

Выполненное поручение

Невыполненное поручение

q1

0.336110

0.145323

q2

0.314079

0.318551

q3

0.051390

0.149953

q4

0.098713

0.059388

Нейронная сеть тестировалась на работе с данными, не входящими в первоначальную выборку. Абсолютная погрешность между значениями, рассчитанными с помощью нейронной сети, и значениями, рассчитанными по методу РОДАР, составила не больше 14%. Этот результат объясняется тем, что в расчетах оценок используются различные параметры и различные подходы к их измерению (В РОДАР используется дискретный подход, а в нашем случае непрерывный). 2. Расчет рейтинга Очевидно, что уровень исполнительской деятельности конкретного сотрудника в течение определенного периода времени можно оценить только в сравнении с аналогичной деятельностью других сотрудников. Будем называть этот уровень рейтингом [2]. Рейтинг исполнителя предполагается рассчитывать в виде коэффициента исполнительской деятельности (КОИ) для сотрудника pi. Для расчета КОИ были использованы пять нижеописанных способов. 1. Расчет рейтинга без использования абсолютной оценки (вариант 1) [2]:

N

KOИ рi =

р

∑ Wn i

n =1 N

M

р р ∑ Wn i + ∑ Wm i

n =1

,

m =1

здесь в числителе стоит суммарная оценка выполненных поручений (N - количество выполненных поручений), а в знаменателе – сумма оценок выполненных и невыполненных поручений (М – количество невыполненных поручений). Удобно что, коэффициент имеет только положительные значения, лежащие на отрезке [0,1]. 2. Расчет рейтинга с использованием ранжированной абсолютной оценки (вариант 2):

N

KOИ рi =

Wnрi n =1

∑

M

− ∑ Wmрi m =1

N +M

, 95

здесь в числителе стоит разность между суммарными оценками выполненных поручений и невыполненных поручений, а в знаменателе – суммарное количество поручений для данного сотрудника. 3. Расчет рейтинга с использованием подхода, который рассматривает оценку, как случайную величину (вариант 3): N M рi рi pi n m n =1 m =1

W = ∑W

− ∑W

1 L W = ∑ W pi L i =1 2

L 1 , σ = (∑ (W pi − W ) ) L − 1 i =1 2

КОИ pi =

W pi − W

σ

здесь в числителе стоит разность между абсолютной оценкой и средним выборочным значением оценки среди всех сотрудников организации, в знаменателе стоит корень из средней выборочной дисперсии, которая характеризует разброс оценок в организации. 4. Расчет рейтинга с использованием подхода, который рассматривает оценку, как случайную величину, с нормировкой (вариант 4): N M W = W nр i − W mр i n =1 m =1 N +M 1

∑

W =

σ2 = КОИ

∑

N +M

∑ Wi

i =1

2

N +M 1 ( ∑ (W i − W ) ) N + M − 1 i =1 pi

=

Wi − W N

σ ( ∑ W nр i + n =1

M

р

∑ Wm i )

m =1

Этот подход отличается от предыдущего тем, что средняя оценка и дисперсия рассчитывается только для поручений выполняемых этим сотрудников, а не для всех сотрудников организации. 5. Расчет рейтинга с нормировкой для средних арифметических оценок (вариант 5):

KOИ рi

1 N рi 1 M рi ∑Wn − ∑Wm N n =1 M m=1 ' = N M 1 рi рi ( ∑ Wn + ∑Wm ) N + M n =1 m =1

здесь в числителе стоит разность между средними арифметическими оценками выполненных поручений и невыполненных поручений, а в знаменателе – среднее арифметическое суммы оценок всех поручений. На основе статистических данных, полученных из системы электронного документооборота, были рассчитаны рейтинги, пятью приведенными способами (рис. 1). В качестве основного рейтинга был выбран третий вариант расчета. На рис. 1 можно видеть, что этот рейтинг не принимает крайних значений, таких как ноль или единица (рейтинг 1, 5), так как в этом случае рейтинг характеризует только факт выполнения или невыполнения поручений и не учитывает качество выполнения. Для оценки меры качества была выбрана разность между суммарными оценками выполненных и невыполненных поручений (на рис. 1 эта величина обозначена как «разность»). С этой мерой наиболее хорошо коррелируют значения «рейтинга 3» и «рейтинга 4». «Рейтинг 3» ведет себя наиболее плавно и равномерно, не наблюдается больших разрывов в значениях соседних рейтингов, 96

Труды конференции Телематика’2010

наилучшим образом ложится на среднее значение рейтингов, рассчитанных по представленным вариантам.

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

Рис. 2. Сравнение оценок рассчитанных предлагаемым методом и методом РОДАР Наблюдается расхождение в значениях оценок для сотрудника №2 первого отдела и для сотрудника №1 второго отдела. В первом случае такая разница вызвана значениями параметров «Точность в сроках выполнения» и «Стабильность выполнения поручений». Оба параметра в рассматриваемом примере меньше среднего, в этом случае РОДАР накладывает достаточно большой штраф. В нашей модели оценка непрерывно убывает пропорционально времени «просроченности» поручения. Во втором случае на расхождение оценок влияет значение параметра «Уровень агрегированности», вклад которого в случае РОДАР для низшего уровня иерархии выше, чем в описываемом подходе. В остальном оба метода дают примерно одинаковую в качественном плане интерпретацию исполнительской деятельности сотрудников. И, хотя наличие одного поручения в системе исполнительской деятельности является вырожденным случаем, данный пример показывает адекватность оценки, получаемой с помощью предлагаемого подхода.

97

4. Реализация На основе описанной модели исполнительской деятельности была реализована библиотека процедур для вычисления оценки поручений и рейтинга сотрудников в рамках системы поручений СЭД, используемой в КемГУ. В данной работе использованы статистические данные за полугодовой период внедрения (создано 280 поручений, 213 поручений выполнено, 67 поручений находились в стадии выполнения на момент получения рейтинговых оценок). В таблице 2 приводятся результаты вычисления. Таблица 2. Рейтинг сотрудников, полученный различными способами № п\п

ФИО

Количество поручений выполненных

невыполненных

Разность

Рейтинг

1

Сотрудник 1

30

0

20.9228

1.0000

2

Сотрудник 2

31

1

20.3222

0.9461

3

Сотрудник 3

21

1

10.9433

0.9043

4

Сотрудник 4

19

2

8.1440

0.7807

5

Сотрудник 5

18

6

7.6000

0.5063

6

Сотрудник 6

13

3

7.2582

0.6873

7

Сотрудник 7

16

6

6.1088

0.4672

8

Сотрудник 8

38

22

3.4847

0.1220

9

Сотрудник 9

5

0

2.4386

1.0000

10

Сотрудник 10

6

4

0.9762

0.1736

11

Сотрудник 11

8

7

0.7694

0.0892

12

Сотрудник 12

2

1

0.4456

0.2856

13

Сотрудник 13

1

0

0.3075

1.0000

14

Сотрудник 14

0

1

-0.5435

-1.0000

15

Сотрудник 15

1

3

-1.0865

-0.4869

16

Сотрудник 16

5

9

-3.3178

-0.4238

Заключение В процессе проведения исследований были выявлены основные требования к оценке со стороны руководителя и со стороны исполнителя. С учетом требования автоматического расчета оценки, выделены ее характеристики. Построена математическая модель исполнительской деятельности. На примере показана достоверность модели. Полученная система оценки позволяет обеспечить активную обратную связь «руководитель– исполнитель», снизить невыполнение решений по вине исполнителя, повысить адекватность оценки исполнителей, создать условия перехода от системы оценки к системе стимулирования труда исполнителя. Отличительными чертами предлагаемого подхода являются: • подсчет оценки автоматический, не требует наличия экспертов; • значения параметров непрерывны, вследствие чего достигается большая точность оценки; • легко добавлять новые и редактировать существующие параметры; • большее число параметров, участвующих в оценке; • наличие комплексных оценок, зависимых от нескольких характеристик; • ориентация оценки на конкретного исполнителя, учет его опыта, заслуг перед организацией, загруженности и напряженности труда; • наличие коэффициентов qi, которые могут задаваться «вручную» из эмпирических соображений, либо обучаться с помощью нейронной сети, позволяет «акцентировать» получаемые оценки на различных сторонах исполнительской деятельности. Описанная модель оценки исполнительской деятельности и ее реализация могут применяться для подсчета рейтинга сотрудников в любых организациях, в которых присутствует какая-либо информационная система управления или система документооборота с накопленными статистическими данными. Полученная методика оценки проходит опытную эксплуатацию в Кемеровском государственном университете и будет способствовать повышению эффективности управленческой деятельности. Литература 1. Друкер П.Ф. Эффективный управляющий / Друкер П.Ф. – М.: СП «Бук Интернешнл», 1994. – 149 с. 98

Труды конференции Телематика’2010

2. Ехлаков Ю.П., Кириенко В.Е., Сенченко П.В. Методы и технологии документационного обеспечения управленческих решений / Ю.П. Ехлаков, В.Е. Кириенко, П.В. Сенченко – Томск: Томский государственный университет систем управления и радиоэлектроники, 2005. – 176 с. 3. Садков В.Г. и др. Стратегии комплексного развития регионов России и повышение эффективности регионального менеджмента / В.Г. Садков, В.Е. Кириенко, Т.Б. Брехова, Е.А. Збинякова, Д.В. Королев – М.: ООО «Прогресс ИД», 2008. – 364 с. 4. Юшкова О.В., Богомягкова Е.А., Шакун Д.Ю. Конкурентоспособность управленческих кадров Пермской области [Электронный ресурс] / О.В. Юшкова, Е.А. Богомягкова, Д.Ю. Шакун – Режим доступа: http://www.atrix.ru/publish9.htm (дата обращения: 20.11.2008).

РАЗРАБОТКА ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНОГО ПОРТАЛА ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ ДЛЯ ПРОВЕДЕНИЯ НАУЧНЫХ И ИНЖЕНЕРНЫХ РАСЧЕТОВ Н.Н. Окулов Кемеровский государственный университет E-mail: [email protected] Введение Стремительное развитие глобальных информационных и вычислительных сетей ведет к изменению фундаментальных парадигм обработки данных, которые можно охарактеризовать как переход к распределенным ресурсам и создание инфраструктуры для свободного доступа к ним. Создание информационно-вычислительного портала (ИВП) для работы с высокопроизводительными вычислительными ресурсами (ВПВР) позволит расширить сферу использования ВПВР в научных исследованиях и учебном процессе вузов. Информационно-вычислительный портал Информационно-вычислительный портал является единым пространством для организации образовательной и научной деятельности вуза в сфере решения различных задач с использованием вычислительного эксперимента, проведения научных конференций, хранения и работы с информационными ресурсами, неформального общения в тематических форумах, информировании о событиях, происходящих в учебном заведении. Основными возможностями портала являются: • проведение численных экспериментов, хранение, поиск и обработка информации, получаемой в результате расчетов; • сбор, систематизация, методическая обработка информационных образовательных ресурсов, гибкая система поиска ресурсов; • информационная поддержка проведения научных конференций. Портал объединяет действующие системы: систему новостных лент, систему форумов, включает в себя каталог ресурсов и сервер конференций. В портал также входят система удаленного доступа и управления распределенными вычислительными ресурсами (УД и УРВР) и виртуальная лаборатория как ее подсистема. Планируется интеграция вычислительных систем портала с инженерным пакетом GiD. Осуществляется тесное взаимодействие с системой поддержки учебного процесса (СПУП). Компоненты портала: система УД и УРВР, являющаяся информационной средой для проведения численных экспериментов и хранения результатов, и система «Виртуальная лаборатория» для анализа эффективности параллельных алгоритмов, – образуют единый самостоятельный программный комплекс для организации удаленного доступа к вычислительным ресурсам и анализа результатов расчетов, позволяющий расширить сферу использования высокопроизводительных вычислительных ресурсов. В КемГУ также ведется разработка систем для поддержки параллельных вычислений: система автоматического обнаружения ошибок и контроля корректности MPI-программ и системы автоматизированного поиска шаблонов неэффективного поведения параллельных программ, – которые будут включены в состав ИВП. Система удаленного доступа и управления распределенными вычислительными ресурсами В современной науке для изучения физических явлений широко используется численный эксперимент. Для получения высокой точности результатов необходимо использовать математические модели, как можно более точно описывающие изучаемые процессы. Чтобы провести численный эксперимент за приемлемое время, необходимо использовать высокопроизводительные вычислительные ресурсы, то есть ресурсы с параллельной архитектурой. Поэтому создание системы УД и УРВР, являющейся информационной средой для проведения численных экспериментов и хранения результатов, является актуальной и важнейшей задачей повышения эффективности и удобства использования ВПВР в научных и инженерных исследованиях.

99

Система управления распределенными вычислительными ресурсами выполняет мониторинг состояния удаленных кластерных установок различных архитектур, осуществляет запуск расчетных программ на свободных ресурсах и обеспечивает хранение результатов расчетов. Данная система сочетает в себе возможности удаленного доступа с графическим интерфейсом пользователя, пакетной обработки заданий и мониторинга состояния ресурсов. Для обеспечения заданной функциональности в системе реализованы следующие возможности: • хранение файлов расчетных программ пользователей ИС (далее «программ») в виде исходного и/или бинарного кода, файлов начальных данных, результатов и другой информации, необходимой для проведения научных расчетов; • хранение и сопровождение информации (метаданных) о файлах и других объектах пользователей; • передача файлов с кодами программ, начальными данными или результатами между пользовательским приложением и хранилищем данных; • создание, удаление и управление пользователем своими объектами (файлами, расчетами); • хранение информации о доступных вычислительных ресурсах; • отслеживание состояния доступных удаленных вычислительных ресурсов; • отслеживание состояния расчетных программ на удаленных вычислительных ресурсах; • передача файлов между хранилищем и удаленными вычислительными ресурсами; • передача команд на удаленные вычислительные ресурсы; • определение очередности запуска программ в случае существования конкуренции за вычислительные ресурсы; • предоставление пользователю удобного графического интерфейса для работы с системой в удаленном режиме. При разработке системы было учтено дополнительное обстоятельство. Характерной особенностью многих университетских сетей, включая и сеть Кемеровского государственного университета, является скрытие значительного количества вычислительных ресурсов за трансляторами сетевых адресов (Network Address Translators – NAT). Таким образом, данные ресурсы не могут быть вызваны с терминалов вне локальной подсети. Дополнительным требованием к системе управления распределенными вычислительными ресурсами стала возможность корректной работы, в том числе, и с такими ресурсами. Принимая во внимание распределенный характер обработки информации в данной системе, для нее была выбрана многозвенная клиент-серверная архитектура. Структура системы представлена на рис. 1.

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

100

Труды конференции Телематика’2010

Менеджер вычислительных ресурсов отвечает за взаимодействие с удаленными кластерами. Периодически просматривая базу данных, менеджер выбирает из нее новые задания на компиляцию программ и запуск расчетов. Удаленный агент – программа на языке C++, устанавливаемая на каждый удаленный вычислительный ресурс для связи с менеджером. Агент отслеживает состояние кластера (количество и загрузку узлов, количество запущенных задач) и периодически выполняет подключение к серверу для передачи информации о состоянии управляемого им ресурса. Агент общается с сервером по собственному протоколу через TCP-сокеты, что позволяет серверу абстрагироваться от специфики архитектур и команд удаленных ресурсов, поскольку эту специфику реализует агент. Для работы с системой пользователь использует программу-клиент (браузер), которая выполняет функции отображения данных, то есть обеспечивает интерфейс. В качестве хранилища данных выступает СУБД Oracle, а связующим звеном браузера пользователя и хранилища является web-сервер приложений Tomcat, который осуществляет динамическую генерацию страниц с использованием пакета KemsuWeb. Такая архитектура позволяет работать с системой из любой точки, имеющей выход в Интернет, а также обеспечивает независимость от платформы и минимальные системные требования к аппаратному обеспечению пользователя. Менеджер вычислительных ресурсов обеспечивает передачу файлов из хранилища, а также запросов на генерацию исполняемого кода и выполнение расчетов из хранилища данных агентам, размещенным на вычислительных кластерах, а также осуществляет прием результатов расчетов и размещение их в хранилище данных. Логически система УД и УРВР разделяется на две подсистемы: систему управления распределенными вычислительными ресурсами и систему удаленного доступа к распределенным вычислительным ресурсам, являющейся средством доступа к системе управления распределенными вычислительными ресурсами, т.е. клиентской частью данной системы. Взаимодействие между данными подсистемами, а также интеграция с системой «Виртуальная лаборатория», осуществляется на уровне общей базы данных. В зависимости от привилегий пользователя, интерфейс клиентского приложения системы может быть двух типов: интерфейс пользователя и интерфейс администратора, которые различаются доступными функциями. Функции, доступные пользователю, связаны с управлением проектами, сериями и расчетами, заданиями и результатами вычислений. Функции администратора относятся к управлению вычислительными ресурсами, пользователями, очередью заданий и просмотру статистики работы системы. Структура пользовательских данных системы включает в себя следующие объекты: Проект – структура, объединяющая все данные, связанные с проведением конкретного вычислительного эксперимента. Проект включает в себя: • набор файлов с исходным кодом расчетной программы; • правила компиляции (make-файл); • исполняемый код расчетной программы (формируется системой путем компиляции исходного кода; если в ходе компиляции произошла ошибка, ее текст будет добавлен в проект); • расчеты, объединенные в серии; • набор файлов с результатами расчетов либо описанием возникших в ходе расчета ошибок. Кроме набора данных, проект также обладает набором свойств, определяющих порядок выполнения заданий в рамках данного проекта (архитектура вычислительной системы, операционная система, версия компилятора и т.п.). Расчет – совокупность выполняемого кода программы и набора файлов начальных данных; на основании одного расчета может быть создано множество заданий. Задание – совокупность расчета и параметров его запуска (выбранный кластер, количество процессоров, время старта), является единицей обработки СУ РВР; каждое задание в системе выполняется ровно один раз. (Под термином «задание» понимается задание на запуск расчетной программы, в отличие от задания на компиляцию, которое является служебным, создается и обрабатывается автоматически и скрыто от пользователя). Виртуальная лаборатория Компонент «Виртуальная лаборатория» системы УД и УРВР разработан с целью организации виртуального лабораторного практикума с использованием высокопроизводительных вычислительных ресурсов в удаленном режиме в рамках курсов по высокопроизводительным вычислениям. «Виртуальная лаборатория» является компонентом системы УД и УРВР, поэтому построена по аналогичной архитектуре и интегрирована в схему БД системы УД и УРВР. «Виртуальная лаборатория» взаимодействует со СПУП, являющейся частью информационно-вычислительного портала КемГУ. «Виртуальная лаборатория» решает следующие задачи: • Предоставление механизма для формирования лабораторного задания в рамках курса по высокопроизводительным вычислениям, предусматривающего исследование поведения определенного численного алгоритма на вычислительных ресурсах кластерной архитектуры (например, зависимость эффективности алгоритма от количества процессоров и параметров задачи). • Предоставление возможности просмотра текста лабораторной работы, а также выполнения задания и просмотра результатов для проведения анализа. 101

В соответствии с задачами системы были выделены два типа пользователей «Виртуальной лаборатории»: преподаватель и студент. Диаграмма вариантов использования системы представлена на рис. 2.

Рис. 2. Диаграмма вариантов использования «Виртуальной лаборатории» Основная функция, доступная студенту – выполнение лабораторной работы с использованием различных параметров запуска. Преподаватель дополнительно имеет возможность управления лабораторными работами (создание, редактирование, удаление). Типовой сценарий работы преподавателя с «Виртуальной лабораторией»: создание лабораторной работы, задание параметров работы и их начальных и предельных значений, задание параметров компиляции, отправка на компиляцию. Типовой сценарий работы студента с «Виртуальной лабораторией»: получение задания (через СПУП), задание значений параметров запуска работы, запуск лабораторной работы, получение результатов и их анализ, формирование отчета о выполнении, загрузка отчета в СПУП. Преподаватель может создавать два типа лабораторных заданий: 1. Анализ заданной программы. Данный тип задания предполагает исследование студентом параметров заранее подготовленной преподавателем программы (например, зависимость эффективности программы от количества вычислительных узлов кластера, или зависимость точности вычислений от размерности задачи). Для данного типа задания преподаватель обязан посредством webинтерфейса разместить в системе исходный код программы, указать количество параметров, их имя, тип и диапазон принимаемых значений (например, размерность задачи может указываться параметром SIZE типа INT в диапазоне от 100 до 10000), указать архитектуру и операционную систему вычислительного ресурса, а также компилятор, которым можно откомпилировать данный исходный код. Значения входных параметров будут переданы программе в виде аргументов в той последовательности, как они заданы преподавателем для данной работы. 2. Разработка программы. Данный тип задания не требует от преподавателя предоставления готового исходного кода. Студент самостоятельно пишет исходный код, размещает его в системе удаленного запуска заданий на вычислительных ресурсах, запускает задание и анализирует результаты. Основным пользовательским объектом в системе является лабораторная работа, которая содержит набор входных параметров работы и список проектов. Поддержка создания нескольких проектов в рамках лабораторной работы необходима для обеспечения возможности запуска на кластерах различной конфигурации (имеют значение вычислительная архитектура кластера, операционная система, используемые компиляторы). Таким образом, один численный алгоритм может быть скомпилирован различными компиляторами для выполнения на кластерах с различными операционными 102

Труды конференции Телематика’2010

системами и вычислительными архитектурами. Значения входных параметров работы (например, количество итераций или размерность матрицы) можно варьировать при запуске лабораторной работы. Результаты выполнения расчетов представляются в виде таблицы, с указанием всех использованных при запуске параметров. Блок анализа результатов вычислений позволяет получить значения эффективности и ускорения по выбранным пользователем расчетам, а также построить диаграммы, отражающие зависимость времени выполнения от набора использованных при запуске параметров. В данное время происходит наполнение базы виртуальных практикумов лабораторными заданиями разной тематики. Также в систему планируется включить разработанную в КемГУ библиотеку параллельных программ HydroParaLib, предназначенную для решения задач гидродинамики. В дальнейшем планируется интеграция в систему библиотек параллельных программ различной направленности. Создание информационной системы для поддержки учебного процесса с возможностью проведения виртуальных практикумов является актуальной задачей информационного обеспечения учебно-научного процесса. Данная система может использоваться в качестве средства для анализа зависимости ускорения, эффективности параллельной программы от значений различных параметров задачи, что актуально как для учебных, так и для научных целей. Благодаря интеграции в информационновычислительный портал КемГУ, доступ к разрабатываемой системе может получить любой пользователь сети Интернет. На данный момент разработан прототип ИВП для организации и проведения высокопроизводительных вычислений, реализованы основные функции подсистем портала, в том числе системы удаленного доступа и управления распределенными высокопроизводительными ресурсами. ИВП внедрен в тестовую эксплуатацию. Ведется разработка системы мониторинга состояния вычислительных ресурсов, а также модернизация системы УД и УРВР, включающая усовершенствование алгоритма взаимодействия системы с агентами кластера, архивирование данных, пересылаемых по каналам связи и др. Доступ к «Виртуальной лаборатории» можно получить после регистрации на информационновычислительном портале КемГУ (http://icp.kemsu.ru). На портале также размещены руководства преподавателя и студента по использованию системы.

СИСТЕМА УПРАВЛЕНИЯ НАУЧНОЙ ИНФОРМАЦИЕЙ НА БАЗЕ МОДИФИЦИРОВАННОЙ ГИПЕРТЕКСТОВОЙ ТЕХНОЛОГИИ А.С. Бордычевская, М.А. Быкова, А.П. Савченко Кубанский государственный университет, г. Краснодар E-mail: [email protected], [email protected] Бурное развитие информационных сетей и, в частности, сети Интернет привело к лавинообразному росту количества информации, доступной пользователям сетей. Однако эта информация зачастую является плохо структурированной, часть информации многократно дублируется, а другую очень сложно найти вследствие несовершенства современных технологий поиска. Большинство систем поиска основано на принципах частотного анализа текста и не учитывает семантику документов. Как следствие, возникает ряд проблем, затрудняющих поиск релевантных документов (например, проблема словомонимов, проблема искусственного «раскручивания» сайта путем заполнения его массивом популярных запросов и др.). В этих условиях возникают новые требования к современным поисковым системам. Перечислим некоторые из них: • необходимо, чтобы поисковая машина различала семантику слов и могла выбирать информацию из той области, которая нужна именно сейчас; • необходимо наличие функции ассоциативного поиска, в данном случае под ассоциативным мы понимаем поиск не по точному совпадению, а «по ситуации», т.е. в результатах должно быть отображено не только искомое слово, но и его синонимы, а также слова, близкие по смыслу; • необходимо наличие инструментов визуализации информационных единиц и связей между ними для обеспечения возможности графической навигации по сети документов. Технологией, позволяющей реализовать указанные возможности, на наш взгляд, могут стать семантические сети, интегрированные в уже существующие сети связанных документов, например, сеть Интернет. Прообраз семантических сетей встречается еще в XVIII в., например, в работах К. Линнея по систематизации биологических видов. В современном виде семантические сети активно серьезно разрабатываются с середины XX века. Однако в 1970–80-х гг., когда искусственный интеллект как научное направление перешел от рассмотрения примитивных «игрушечных» сред к решению реальных задач выявились многочисленные недостатки представления знаний в виде семантических сетей. К наиболее серьезным недостаткам относят следующие [1]: • семантические сети качественно описывают лишь статические структуры, но не динамические объекты и процессы; 103

• при расширении границ описываемой области реальной среды, количество связей в семантической сети растет экспоненциально, поскольку в реальности каждый объект связан с огромным количеством других объектов. Это приводит к тому, что сети становятся перегруженными, плохо читаемыми и практически бесполезными; • неоднозначность и субъективность восприятия отношений между понятиями проводит к тому, что одну и ту же связь можно представить по-разному. Например, конструкцию «у орла большие крылья» можно представить как минимум двумя способами: • Орел – (крылья) – большие; • Орел – (имеет) – крылья – (размер) – большие. Более того, даже характер связей между понятиями иногда трактуются разными исследователями прямо противоположно. Поэтому сети, созданные разными разработчиками, часто несовместимы друг с другом. Однако, на наш взгляд, при переходе от описания связей между объектами реального мира к описанию связей между документами семантические сети имеют все же больше достоинств, чем недостатков. Детально рассмотрим эти особенности далее. Уже достаточно давно ведутся исследования в области создания систем поиска, использующих семантические свойства документов. Наиболее существенные результаты получены в рамках технологий семантического веба, SemanticWiki и микроформатов. Концепция Семантического Веба [2] является наиболее проработанной и универсальной из всех перечисленных. Однако возможность ее практической реализации вызывает серьезные сомнения. Критики называют такие существенные недостатки, как невозможность создания единой онтологии понятий, невозможность получения коммерческой выгоды от рекламы в семантическом вебе, необходимость дублирования исходной информации в метадокументах. На сегодня, концепция семантического веба осталась лишь теорией и не получила серьезного распространения. Дочерними технологиями семантического веба можно считать многочисленные микроформаты, позволяющие создавать семантическую разметку в рамках отдельно взятой предметной области с помощью стандартных инструментов языка HTML (XHTML). Главным недостатком микроформатов считается их узкая специализация, изолированность и отсутствие стандартизации, что делает их объединение практически невозможным. Технология SemanticWiki предполагает дополнение традиционных энциклопедических статей метаданными и типизированными ссылками, что позволяет автоматически обрабатывать статьи в поисках ответа на запрос пользователя [3]. Несмотря на массу достоинств, эта технология имеет ряд существенных ограничений: • технология SemanticWiki предполагает работу со статьями энциклопедического характера, для которых можно однозначно сформулировать их основной предмет (как правило, он вынесен в название статьи), тогда как при работе со сложными документами, такими как научные статьи или книги невозможно выделить одно ключевое понятие, что затрудняет использование данной технологии. • при установлении связей между документами не указывается адрес документа, а указывается только ключевое слово, поскольку предполагается, что каждому понятию предметной области в данной семантической сети соответствует строго одна статья; при работе с научными статьями такое ограничение нарушается, поскольку под ключевым словом, например, «менеджмент» может скрываться ссылка на любой из десятков учебников по менеджменту или на одну из тысяч статей по этому направлению. Таким образом, можно сделать вывод, что достаточно универсальной и в то же время простой в использовании технологии организации связей между разнородными документами со сложной структурой не создано. Поэтому, авторы предприняли попытку создания такой технологии. Цель данной работы – разработка универсальной, простой в использовании технологии организации семантической сети документов и информационной системы управления научной информацией на базе этой технологии. Описание технологии. Предлагаемая технология представляет собой расширение традиционной гипертекстовой технологии за счет внедрения метаданных в текст HTML документа с помощью элементов XML или хранения их в отдельных XML-файлах. Хранение метаданных организовано с помощью так называемых категорий. Категории представляют собой ключевые характеристики документа, такие как автор документа, дата и место публикации, а также перечень основных понятий, описывающих документ. Например, чтобы указать Иванова И.И. в качестве автора документа нужно установить связь этого документа с категорией «Иванов И.И.», задав имя отношения – «автор». Категории описаны с помощью XML-файлов, содержащих список документов, принадлежащих категории и описания связей этой категории с другими. Файлы категорий расположены в специальном каталоге, едином для сегмента сети, благодаря чему пользователю достаточно знать только имя категории, а не полный адрес соответствующего файла. Создание файлов категорий происходит автоматически при наличии нескольких (например, больше 2) документов, заявивших о принадлежности к данной категории. Благодаря такой системе хранения метаданных существует возможность работы с документами произвольного формата, поскольку в текст документа никаких изменений вносить не требуется. 104

Труды конференции Телематика’2010

Технология не предусматривает сложных процедур семантической разметки документа пользователем, внедрение метаданных происходит автоматически и не сказывается на отображении документа в обычном браузере. В то же время наличие метаданных позволяет (как в случае с микроформатами) специальным программам находить дополнительные данные и осуществлять поиск документов по семантическим признакам. Все категории организованы в систему понятий, объединенных между собой разнотипными именованными связями. Частным случаем являются связи типа «часть/целое», благодаря которым категории могут включать подкатегории, образуя иерархическую внутреннюю структуру. Разнообразие, необязательность и множественность связей позволяет избежать проблем, характерных для традиционных иерархических онтологий, при этом позволяя совмещать достоинства фасетной и иерархической классификаций. Технология предусматривает 3 типа связей: «документ – документ», «документ – категория», «категория – категория». Каждая связь может иметь два имени, соответствующие прямому и обратному отношению между объектами. Связь «документ – документ» не учитывает внутреннюю семантику текста, имеет ограниченный набор типов связей (например, продолжение/начало, включает/является частью, ранняя/поздняя версия, цитируемый/цитирующий документ). Данный вид связи единственный, который внедряется в текст HTMLдокумента с помощью XML-тегов. Для работы c не-HTML документами создаются XML-оболочки, содержащие указанную информацию. Связь «категория – категория» учитывает семантику, имеет неограниченное количество типов, формирует онтологию предметной области. В гиперссылке указан модифицированный URL для категорий – UEL (Unified Entity Location). Связь «документ – категория» на данном этапе разработки ограничена только одним типом и описывает вхождение документа в категорию, не конкретизируя роли информационных единиц. Пример XML файла для категории «Интеллектуальная система» с информацией о связях приведен ниже:

<docs> <doc name = "Инструменты интеллектуального анализа данных"> В файле категории существует два раздела: Links – содержащий связи данной категории с другими, и Docs – содержащий список документов, принадлежащих этой категории. Приведенные в примере XML-теги содержат информацию о связи понятия «Интеллектуальная система» с понятием «Нейронные сети» (имя отношения – механизм) и о принадлежности документа «Инструменты интеллектуального анализа данных» к категории «Интеллектуальная система» (имя отношения не задано). Ожидаемые результаты. На базе предложенной технологии разрабатывается информационная система управления научными документами. В информационной системе планируется реализовать следующие возможности: 1. Два типа поиска документов: полнотекстовый и ассоциативный (поиск документов, близких по смыслу). Ассоциативный поиск осуществляется следующим образом: в первую очередь ведется поиск по парам «название категории» – «имя связи». Например, при запросе «функции управления» наиболее релевантным результатом будут считаться категории, связанные с категорией «управление» связью с именем «функция». Следующий по релевантности результат – совпадение только в названиях категорий, затем – совпадения в тексте документа и наконец – в именах отношений. При обнаружении искомого слова в названии категории пользователь увидит все документы, входящие в эту категорию, даже если в самом документе и не встречается искомое слово. 2. Работа с визуальной картой понятий (категорий), позволяющей вручную находить связанные понятия и документы. Зачастую пользователь, особенно если он не специалист в предметной области, лишь в общих чертах представляет себе что искать, не может достаточно конкретизировать запрос и потому не находит нужных документов. Карта категорий позволяет увидеть связи между понятиями, «вручную» дойти до нужной категории и просмотреть ее содержимое. 3. Фильтрация документов по атрибутам: по автору, дате, типу публикации с использованием метаданных. 4. Автоматический подбор списка научных публикаций по заданной тематике; 5. Автоматическое формирование единого документа из отдельных частей, помещенных в базу (например, сбор книги из отдельных опубликованных глав, соединение серии статей в одну) и др. На данном этапе реализованы следующие модули: 105

• редактор категорий, позволяющий создавать/редактировать категории и устанавливать связи между ними; • редактор метаданных, позволяющих включать документы в нужные категории; • визуализатор семантической карты категорий; • и прототип семантического браузера, позволяющего извлекать метаинформацию и автоматически находить документы, близкие по смыслу. Таким образом, в данной работе рассмотрены основные достоинства и недостатки семантической сети как метода представления связанных понятий, проанализировано использование семантических технологий в сети Интернет, показано, что интеграция информационной сети связанных документов (например, сети Интернет) и семантической сети понятий позволит получить синергетический эффект. Предложена технология организации семантической сети документов на базе языков разметки HTML и XML. Представлен проект информационной системы работы с научной информацией с возможностью ассоциативного поиска. Опытную эксплуатацию и тестирование системы планируется осуществить на базе кафедры общего, стратегического, информационного менеджмента и бизнес-процессов КубГУ в начале 2011 г. Литература 1. Егоров А. Искусственное сознание (Сети: нейронные или семантические?). URL: http://www.robohomo.ru/robo-lenta/robo-debates/136.html. 2. Бернерс-Ли Т., Хендлер Дж., Лассила О. Семантическая Сеть: пер. с англ. URL: http://ezolin.pisem.net/logic/semantic_web_rus.html. 3. Volkel M., Krotzsch M., Vrandecic D., Haller H., Studer R. Semantic Wikipedia. URL: http://www2006.org/programme/files/xhtml/4039/xhtml/fp4039-voelkel.html.

СИСТЕМА СОПРОВОЖДЕНИЯ ИГРОВОГО ОБУЧЕНИЯ И.С. Игнатьев Московский государственный институт электроники и математики (технический университет) E-mail: [email protected] Общая концепция системы Даже при наличии возможности использования аппаратных и программных средств, прежде доступных только на производстве, многие студенты ею не пользуются в силу сложности реальных и более высокой ответственности за их выполнение. Данные проблемы решаются современными методами обучения: активными методами и игровыми методами [1, 2]. На базе этих методов для решения этой проблемы было решено создать компьютерную систему сопровождения игрового обучения для обучения ИКТ (СИО). Для выполнения задания при использовании инструментария проектирования игровых проектов была разработана методика игрового обучения ИКТ на инженерных специальностях. В ходе обучения студенты развиваются в рамках своих ролей – будущих профессий – на основе постоянной автоматической – при использовании анализа поступающих в систему данных о прогрессе студента в определенной игре – оценки различных действий студентов. В системе возможны, как компьютерные игры – в этом случае данные собираются также автоматически при помощи клиентского программного обеспечения системы, так и другие виды игровой деятельности – в этом случае требуется ввод данных в систему ручным путем. Благодаря постоянной оценке и развитию студент чувствует себя постоянно задействованным и стремится максимально раскрыть свой потенциал [3]. Гибкость методике придает ориентация не на непосредственно на оценку студента в качестве актора какой-либо профессии, а оценку навыков студента, которые в совокупности показывают общий уровень развития студента, что оценивается в уровне развития в профессии как в агрегированном параметре. Также разработанная методика позволяет на основе навыков студента автоматизированно составлять его резюме, что повышает ее полезность для студента. Система позволяет наблюдать обучение (прежде всего, в группе) и выявлять неявные его закономерности. Общий алгоритм работы системы следующий: пользующиеся системой в обучении используют специально модифицированные для системы игры, которые периодически отправляют отчеты о прогрессе обучающегося в единую базу данных, по материалам которой и отслеживается различными интеллектуальными методами анализа данных общий прогресс обучения, и строятся и проверяются различные предположения об их обучении. Архитектура СИО С архитектурной точки зрения СИО представляет собой систему с многозвенной (трехзвенной) клиент-серверной архитектурой. Серверами системы являются: • сервера сбора результатов обучающих игр Sg; • сервера анализа результата обучающих игр Sa; 106

Труды конференции Телематика’2010

• сервера хранения результатов обучающих игр Sm; • сервера представления результатов анализа Sw. Сервера хранения результатов обучающих игр Sm являются серверами баз данных, остальные сервера являются серверами приложений, так как несут различную функциональную нагрузку в рамках СИО. Клиентами СИО являются клиент на машине пользователя C, который обеспечивает сбор результатов игрового обучения, и интернет-браузер, с помощью которого пользователь получает доступ к аналитической информации, полученной по результатам игрового обучения. Серверная часть системы Сервер получает данные, расшифровывает их и упорядоченно помещает в соответствующие таблицы базы данных. По мере накопления данных появляется возможность их анализировать, для этого сервер предоставляет свои инструменты анализа данных. Результат анализа должен быть представлен пользователю. Получение и проверка данных Данные в целях ускорения передаются по ненадежным каналам и могут исказиться, и соответственно требуется не только их принять, но и как можно быстрее сохранить. Для этого после получения пакета требуется как можно скорее его проверить на соответствие формальным требованиям со стороны протокола и, опять же с наименьшими затратами по возможности, далее сохранить в постоянное хранилище данных. Для того чтобы реализовать проверки, которые позволят отбрасывать поврежденные пакеты, следует предусмотреть нужный механизм. Так, для этого можно использовать проверяющие парсеры xml-кода. Также это позволит прозрачно перейти от представления данных в передаваемом через сеть пакете к представлению данных в их хранилище [4]. Для устранения возможности блокировки приема информации прием является максимально асинхронным. Для этого для каждого пакета следует не обрабатывать его в основной программе приема, а порождать дочернюю программу, которая уже будет обрабатывать пакет, проверять его корректность и сохранять в базе данных [5]. Также для того, чтобы сохранение в базу данных не стало узким местом, используется асинхронное сохранение. Сервер сбора результатов обучающих игр Sg реализован при помощи фреймворка Twisted, который позволяет организовать асинхронную обработку пакетов с сохранением их в СУБД [6]. Был создан запускающийся независимо от основного комплекса демон. Созданы скрипты для его запуска в ОС Debian Linux, подготовлен установочный файл. Конфигурация демона производится при помощи файла конфигурации, находящегося в специально выделенном для этого каталоге. Хранение данных Данные необходимо хранить таким образом, чтобы их можно было достаточно легко считать, и в то же время они не занимали на диске много места. В связи с этим следует отойти от традиционного хранения данных в достаточно быстрых, но неэкономных в смысле места хранения типов хранилищ, таких как MyISAM и InnoDB, в пользу специализированного хранилища, которое предназначено для долговременного хранения больших объемов данных – Archive [7]. Сервер хранения данных представляет собой структуру таблиц, основанную на нескольких различных типах хранилищ. В хранилищах типа InnoDB хранятся данные, которые требуют оперативного доступа и работы с ними: конечные данные анализа, исходные данные для визуализации, учетные данные пользователей, различного вида описания для игр, алгоритмов и т.п., которые в основном обслуживают сервер представления результатов анализа Sw. В хранилище типа Archive хранятся исходные данные (результаты игр), предназначенные для анализа. Их выборка происходит сразу большим объемом, что позволяет пренебречь оперативностью в пользу массовости. Анализ данных Анализ данных – это требовательный к таким ресурсам, как оперативная память и вычислительная мощность, процесс. Он должен запускаться над выбранными данными отдельно от всех остальных процессов, чтобы не вызвать никаких перегрузок системы. Более того, это сложный и долго выполняющийся процесс, а потому его запуск как веб-скрипта сопряжен с большими сложностями. В силу этих причин анализ данных физически выделен из общего функционала серверов в качестве отдельного сервиса, тем более что вполне можно выделить как входные, так и выходные данные для этого сервиса. В качестве входных данных выступают данные о том, какой алгоритм, с какими параметрами и ограничениями и над какими данными следует выполнить. В качестве выходных данных – запись в таблице результатов анализа игр и визуальное представление результата в виде диаграмм Вена и других визуальных средств. Общая схема работы сервера анализа заключается в следующем: • Получив задание на анализ от пользователя системы через сервер представления результатов анализа, сервер анализа проверяет его корректность и достаточность представленных в нем данных. • После этого сервер запускает на основании полученного задания долговременный процесс, который будет осуществлять сам анализ данных непосредственно. 107

• В том случае, если для выполнения процесса анализа данных не хватает ресурсов или превышен интервал ожидания ответа, сервер анализа данных возвращает ошибку серверу представления результата. • По завершении процесса анализа данных сервер анализа данных сохраняет представленные конкретными алгоритмами результаты анализа в стандартизованном виде в БД сервера представления результатов анализа. В результате работы сервер создает в БД сервера представления результатов анализа структуру, на основании которой сам сервер представления отображает результаты анализа данных. Для анализа данных предусмотрено несколько методов анализа. Байесовский классификатор [8] позволяет определять вероятность принадлежности наблюдения или объекта к одному из классов. При этом выдвигается предположение о независимости влияния на эту вероятность различных атрибутов объектов – так называемое предположение об условной независимости классов, которое существенно упрощает сопутствующие вычисления. Простой байесовский классификатор относит объект х к определенному классу Сi тогда и только тогда, когда выполняется условие:

P(Сi|х)>P(Сj|х), где: P(Сi|х) – апостериорная вероятность принадлежности объекта х к классу Сi, P(Cj|х) – апостериорная вероятность принадлежности объекта х к произвольному классу Сj, отличному от Сi. Байесовский классификатор относит объект к определенному классу тогда и только тогда, когда апостериорная вероятность принадлежности объекта к этому классу больше апостериорной вероятности принадлежности объекта к любому другому классу. Классификация деревьями решений – это способ представления совокупности правил в иерархической, последовательностной структуре, пройдя по которому от корня к листу каждому объекту можно сопоставить один единственный узел, соотносящий этот объект и класс, к которому он принадлежит. Алгоритмы построения дерева решений стремятся построить дерево, начиная с корня и далее вниз по узлам дерева до листа, который непосредственно определяет класс, к которому должен принадлежать объект. В частности, так как лист определяет, к какому классу принадлежит объект, зачастую построение делается на основании подсчета наибольшего убывания энтропии обучающей выборки (алгоритм ID3 и его различные модификации) [9]: k

Gain ( x ) = max T (∑ r =1

Freq (Cr , I ) Freq (Cr , I ) k Freq (Cr , T ) Freq (Cr , T ) log 2 −∑ log 2 ) I I T T r =1

где: Freq(Cr, I) – количество объектов определенного класса Cr в исходной выборке I, Freq(Cr,T) – количество объектов определенного класса Сr в выборке после разбиения (и образования нового узла) T. Подсчет производится по всем возможным разбиениям и всем классам, а затем выбирается максимальный выигрыш энтропии и на основании этого выбирается наилучшее разбиение на текущем шаге алгоритма. Кластеризация отличается от классификации тем, что алгоритм не использует обучающую выборку, а делает выводы от принадлежности объектов к определенным классам на основании непосредственно анализируемых данных. Кластеризация позволяет создавать разбиения заданной выборки объектов на непересекающиеся подмножества (кластеры) так, чтобы каждый кластер состоял из схожих объектов, а объекты разных кластеров существенно отличались. Схожесть и различия определяются при помощи специальной метрики, называемой расстоянием. Расстояние может считаться различными способами, но основные его свойства таковы, что чем более схожи объекты друг с другом, тем меньше должна быть эта метрика. Также эта метрика должна быть строго положительной. Иерархическая кластеризация отличается тем, что строит иерархию кластеров по мере своего выполнения. Непосредственно разбиение исходной выборки на кластеры получают из среза этой иерархии в любой момент работы алгоритма. Обычно критерием останова алгоритма для получения правдоподобной картины распределения объектов по кластерам ставят достижение определенного расстояния между объектами или кластерами, которые на следующем шаге должны быть обработаны[10]:

| D ( xj , xi ) |< ε

, где

• хi, xj – n-мерные объекты, которые предложены алгоритмом к объединению в один кластер на данном шаге, • D(хi, xj) – функция расстояния между ними, • е – предварительно выбранное максимальное расстояние, при котором объединения еще будут происходить. Кластеризация методом k-среднего является быстрым методом кластеризации, не относящимся к иерархическим, хотя схожесть элементов и здесь определяется на основании метрики расстояния. 108

Труды конференции Телематика’2010

Основным недостатком данного метода является то, что для его запуска необходимо выдвинуть гипотезу о числе кластеров, содержащихся в исходных данных. На основании этой гипотезы алгоритм образует заданное число кластеров и начнет итеративно перераспределять между ними до тех пор, пока не будет подобрано такое распределение, которое минимизирует расстояние между воображаемыми центрами кластеров (центроидами) и объектами в кластерах. Фактически, данный алгоритм является алгоритмом поиска минимума функции J [11]:

N

K

J = ∑∑ u ij * d ( xi , c j ), где i =1 j =1

• • • • • •

N – число объектов в выборке, K – число кластеров, xi – i-ый объект в выборке, cj – центроид кластера Cj, uij = 1, если xi принадлежит кластеру Cj, иначе uij = 0, d(xi, cj) – метрика расстояния между объектом в выборке и центроидом соответствующего кластера. После выбора на основе метрики расстояния наиболее близкой к объекту центроиды для всех объектов выборки центроиды перевычисляются на основании метода нахождения центра масс, после чего процесс соотнесения повторяется. Этот метод создает плотные кластеры, однако останов алгоритма на любом этапе до его конца не дает верной картины распределения объектов по кластерам. Критерием окончания здесь чаще всего ставится отсутствие достаточно большого сдвига между центроидами на текущем и предыдущем шаге или достижение определенного достаточно большого числа шагов алгоритма (это ограничение необходимо для того, чтобы избежать зацикливания в том случае, когда какой-либо объект находится на границе двух кластеров):

K

∑c i =1

i

t

− ci

t −1

<ε

, где

• сit, cit-1 – центроиды i-ых кластеров на t-ом и t-1-ом шагах соответственно, • K – общее число кластеров, • е – предварительно выбранный минимальный сдвиг центроиды, при котором достигнута нужная нам точность распределения и дальнейшее выполнение алгоритма считается бессмысленным. Представление данных Традиционное представление данных – это их табличная форма. Однако она ненаглядна, особенно в случае большого объема данных. Поэтому для большей наглядности применяют визуализацию этого объема данных. Существуют различные методы визуализации, однако не все из них подходят для конкретных алгоритмов. Для системы же необходимо иметь достаточно универсальные методы визуализации, так как она применяет различные методы анализа и соответственно для этих методов анализа должны применяться различные методы визуализации. Так, например, для анализа деревьями решений следует использовать визуализатор этого дерева, а для любой другой классификации этот визуализатор не подойдет, скорее всего. Таким образом, возникает необходимость применять определенный визуализатор в зависимости от того, какой именно анализ производился над данными. Сервер представления результатов анализа реализован на платформе веб-фреймфорка Django. Выполняемые сервером функции: • Сервер дает возможность пользователю зарегистрироваться для использования базы игр в системе. • После регистрации и ее подтверждения через электронную почту пользователь получает доступ к своему кабинету. • Через кабинет пользователь может скачать необходимое для игры программное обеспечение и начать играть. • В кабинете отражается накопление данных об играх и, как только данных будет достаточно для анализа, доступна функция анализа. • При выполнении этой функции можно выбрать алгоритм и его параметры, доступны умолчания для всех параметров. • Выбранный набор алгоритма и параметров можно сохранить и запустить на исполнение. • По окончании анализа полученные результаты визуализуются как в виде таблицы, так и в индивидуальных для алгоритмов более наглядных видах. Клиентская часть системы Клиент реализует функциональность сбора данных и их отправки на сервер сбора данных. Сбор данных Для сбора данных предусмотрено несколько методов: 109

• Встроенный клиент СИО: при помощи встраивания в непосредственно в обучающую программу. В этом случае сбор данных проходит прозрачно для пользователя. Пользователь использует модифицированную клиентом СИО обучающую программу, и по ходу обучения происходит сбор данных. • Отдельный клиент СИО: при помощи сбора данных, остающихся по результатам выполнения обучающей программы. В этом случае сбор данных происходит периодически. Для сбора данных клиент должен быть запущен вместе с обучающей программой и настроен на сбор данных именно этой программы. Также должна быть определена структура данных для дальнейшей их интерпретации. Передача данных Клиент системы игрового обучения должен производить замеры и отсылать данные о прогрессе учащегося в игре достаточно часто. В связи с этим возникают требования к пропускной способности канала и производительности конечного устройства учащегося. Исходя из этих требований, а также статистической незначимости потери какого-либо отдельного результата учащегося, для передачи данных был выбран протокол UDP. Это позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым требуется большая пропускная способность линий связи, либо требуется малое время доставки данных. Протокол взаимодействия клиента и сервера Для реализации модели СИО был разработан основанный на xml протокол обмена информацией о успехах клиента в игре. Протокол формулирует передаваемые сведения, которые затем могут быть использованы для анализа интересов играющих, их действий, их ошибок, для отладки самих программ, для сбора данных об играющих и оценки их успехов в игре. Основное сообщение протокола имеет следующий вид: <sensor id=id1> sensor1_data <sensor id=id2> sensor2_data ... <sensor id=idn> sensorn_data Протокол используется для обмена между клиентом на машине пользователя и сервером сбора результатов Sg. В основном сообщении указывается уникальный идентификатор игры, получаемый при занесении игры в систему. Сами данные о результатах обучения пользователя систематизированы в соответствии с идентификаторами, которые показывают, что эти данные значат в системе. Область уникальности этих идентификаторов ограничивается каждой конкретной игрой. Для отделения данных разных пользователей друг от друга используется уникальный идентификатор пользователя и хешфункция его пароля. Выводы На основании нескольких фреймворков была реализована сложная система, направленная на внедрение новых методов обучения и их сопровождение, а также улучшение учета, контроля и анализа успеваемости. Преподавателю представлены гибкие интеллектуальные средства анализа различных собираемых данных об успеваемости учеников. Литература 1. 2. 3.

4. 5. 6. 7. 8. 110

Ю.М. Порховник. Активные методы в дистанционном обучении. // Журнал «Дистанционное образование», №1 от 1997 г. Б. Зельцерман и др. Время Эксперимента. Юбилейный выпуск. – Рига: Педагогический центр "Эксперимент", 2002. Brad Paras, Jim Bizzocchi. Game, Motivation, and Effective Learning: An Integrated Model for Educational Game Design. // Proceedings of DiGRA 2005 Conference: Changing Views – Worlds in Play. Документация по библиотеке lxml. lxml.objectify. // Доступно по http://codespeak.net/lxml/objectify.html . Документация по фреймворку Twisted. Using Threads in Twisted. // Доступно по http://twistedmatrix.com/documents/current/core/howto/threading.html Документация по фреймворку Twisted. Twisted RDBMS support. // Доступно по http://twistedmatrix.com/documents/current/core/howto/rdbms.html . Документация по MySQL 5.0. The MySQL 5.0 Archive Storage Engine // Доступно по http://dev.mysql.com/tech-resources/articles/storage-engine.html . George H. John, Pat Langley: Estimating Continuous Distributions in Bayesian Classifiers. // Eleventh Conference on Uncertainty in Artificial Intelligence, 1995.

Труды конференции Телематика’2010

9. J. R. Quinlan. Induction of decision trees. // Machine Learning, Volume 1, Issue 1, 1986. 10. Ward, Joe H. Hierarchical Grouping to Optimize an Objective Function.// Journal of the American Statistical Association 58 (301), 1963. 11. MacQueen, J. B. Some Methods for classification and Analysis of Multivariate Observations. // Proceedings of 5th Berkeley Symposium on Mathematical Statistics and Probability, 1967.

ТЕКСТОВАЯ КЛАСТЕРИЗАЦИЯ АЛГОРИТМОМ ROCK И.И. Савин Московский государственный институт электроники и математики (технический университет) E-mail: [email protected] Введение Большой рост количества информации в электронном виде привел к серьезным проблемам, связанным с ее структуризацией. По данным корпорации EMC [1] на сегодняшний день более 95% цифровой среды состоит из неструктурированной информации. В организациях неструктурированные данные составляют свыше 80% всей информации. Наибольшая часть этих данных содержится в виде текстовых документов. Структуризация наборов текстовых документов может потребоваться для поиска и сравнения похожих текстов, поиска дубликатов, составления списка документов смежной тематики или просто списка рекомендуемых документов. Решением этих задач занимается кластерный анализ текстовых документов. Так как документы написаны на человеческом языке, из которого машине трудно выявлять полезную информацию, одной из важных задач кластерного анализа является представление документов в удобном виде для последующей машинной обработки. Текстовые данные практически в любом представлении имеют свою специфику по сравнению с наборами числовых данных, что необходимо учитывать при выборе алгоритма кластеризации. Целью данной работы является разработка анализатора на основе алгоритма ROCK для последующей кластеризации кафедральной базы знаний, работающей на популярном для использования в образовании движке MediaWiki [2]. Результатом работы является комплекс программного обеспечения, состоящий из программ подготовки текстовых документов и кластеризации, а также расширений для MediaWiki, позволяющих управлять кластеризацией, задавать различные параметры анализа и просматривать результаты анализа. Подготовка текстовых документов Теоретическая часть Текстовый документ с точки зрения машины представляет собой объект, из которого достаточно сложно выявить какие-либо полезные данные кроме размера документа и его метаданных для последующего кластерного анализа. Чтобы это стало возможным, необходимо для начала подготовить текстовый документ, привести его в вид наиболее удобный для анализа машиной. Существует две наиболее распространенные модели представления текстовых документов: древовидная [3] и векторная модели [4]. Древовидная представляет собой наборы цепочек следующих друг за другом слов. Это позволяет затем машинным анализом выявлять среди нескольких документов похожие цепочки и таким образом выявлять их схожесть. Однако, такой вид представления документа наиболее востребован при проверке на плагиат. В случае же с кластеризацией текстовых документов наилучшим представлением документа является векторная модель. Векторная модель документа представляет собой таблицу частоты употребления слов в документе. Такое представление позволяет хотя и с некоторой погрешностью, но достаточно быстро определить ключевые слова текста, а значит и его тематику. В особенности такое правило действует для технической литературы, которая и является основным предметом кластеризации данной работы. В человеческих языках и особенно в русском языке слова имеют достаточно много аффиксов (то есть вспомогательных частей слова, присоединяемых к корню для образования новых однокоренных). Так при составлении векторной модели документа в таблице могут попадаться однокоренные слова с разными окончаниями, которые можно было бы учитывать как одно слово при рассмотрении его тематического значения. Следует заметить, что некоторые аффиксы достаточно сильно меняют смысл слова, поэтому нельзя их рассматривать как незначащие при определении тематического значения (например, «сложный» – «несложный», «использующий» – «используемый»). Значимая часть слова, очищенная от незначащих аффиксов, называется термом. Терм – это основной элемент таблица частоты слов. Говоря о технической литературе, следует заметить, что она обычно имеет некоторую структуру заголовков и элементов форматирования для удобства использования человеком. Заголовки обычно содержат наиболее значимые слова текстового документа. Также заголовки документа обычно имеют 111

иерархию, то есть подзаголовки различного уровня, слова в них также имеют различный тематический вес. Эту особенность также следует учитывать при построении векторной модели документа. После построения векторной модели документа, используя все выше изложенные правила, возникает вопрос о хранении этой модели. Так как модель представляет собой таблицу, наиболее удобно хранить ее с помощью любой реляционной СУБД. Это позволит разумно использовать место на жестком диске и быстро получать доступ к данным модели любого документа. Для большей экономии ресурсов машины следует нормализовать данную таблицу, приведением ее к третьей нормальной форме (3NF) [5]. После преобразования получится таблица с уникальными словами всех документов, участвующих в кластеризации и таблица с идентификаторами записей из таблицы слов и частотой этих слов. Практическая часть Реализация подготовки текстовых данных из базы, используемой движком MediaWiki, имеет ряд особенностей. Структура данных движка представлена следующим образом: имеется таблица с идентификаторами, названиями всех ресурсов имеющихся на сайте (в том числе текстовых, изображений, других медиа, служебных страниц), и ссылкой на сам ресурс. Ресурсы же распределены по таблицам в зависимости от типа данных. Например, все текстовые ресурсы, включая страницы обсуждений, некоторые служебные страницы, элементы дизайна хранятся в одной таблице с основными статьями движка. Также следует учитывать, что помимо актуальной версии текстового ресурса, в базе содержатся все когда-либо существовавшие его версии. Таким образом, прежде всего, необходимо было составить запрос к базе, чтобы получить только актуальные версии статей определенных разделов и связать их со своими заголовками. Рассмотрим подробнее алгоритм преобразования текста в векторную модель. В данной реализации для экономии времени разбор текста происходит посимвольно один раз на каждый текст. В процессе этого разбора отсеиваются все незначимые символы (знаки препинания, незначащая разметка) и происходит выделение отдельных слов для последующего анализа и занесения во временный список термов статьи. При разборе слова сначала происходит проверка его языка и регистра. На данный момент, так как англоязычные статьи не являются предметом кластеризации в данной работе, то разбор проходит только русских слов, однако, при желании дописать необходимую часть не составляет труда. Если длина слова в нижнем регистре не превышает 3 символов, то, скорее всего это предлог и тратить время на его разбор нерационально. Такие короткие слова отбрасываются на этом этапе. Если полученное слово записано в верхнем регистре, то оно считается аббревиатурой и также без более глубокого анализа заносится во временный список термов. Анализ слова производится с помощью стемминга, то есть преобразованием его в терм, определяя часть речи и удаляя присущие этой части речи аффиксы, не меняющие смысла слова сильно. В данной реализации используется достаточно простой, но наиболее быстрый алгоритм Портера [6], адаптированный под русский язык. После составления списка термов документа производится подсчет статистики употребления слов. Также для экономии времени вычислений в цикле подсчета статистики происходит проверка, входит ли терм в список стоп-слов. Стоп-слова – слова, не несущие в себе смысла и не влияющие на его тематику. Такими словами чаще всего являются предлоги, союзы и другие части речи, предназначенные для связи слов в предложениях. Также стоп-словами являются расширения графических файлов, элементы оформления ссылок (“http”, “www”,”net” и т.д.) Также для некоторого набора статей могут существовать свои стопслова, например адрес сайта или названия вспомогательных ресурсов, не определяющих тему статьи. На данный момент список стоп-слов задается разработчиком, но в будущем планируется частично перенести эту функцию на администратора, тем самым сделав инструмент более гибким в настройке. В данной реализации отдельно происходит разбор заголовков. Это обосновывается желанием в дальнейшем иметь инструмент регулировки значимости слов в заголовках. Все процессы, производимые с обычным текстом, также проводятся и с заголовками, отличием является лишь подсчет частоты употребления слов: здесь происходит умножение на коэффициент с учетом уровня заголовка, в котором встречается слово. В реализации расширения для движка MediaWiki имеется параметр «Минимальный размер статьи», задаваемый администратором и позволяющий более гибко проводить подготовку текста. Этот параметр устанавливает минимальный размер документов, участвующих в кластеризации. Некоторые документы могут быть слишком малы, чтобы можно было определить их тематику по частоте употребления слов. Также этот параметр рекомендуется задавать ненулевым и не слишком малым, чтобы не учитывать перенаправляющие статьи и статьи-заглушки (например, «Здесь нужно написать о …»). Кластеризация текстовых документов Теоретическая часть Для того чтобы кластеризовать некоторый набор объектов данных, необходимо выбрать меру близости и собственно алгоритм кластеризации. Мера близости – это функция, определяющая степень похожести двух объектов данных между собой. Эта функция выбирается на основании типов и количества атрибутов у каждого объекта, а также требований к вычислительной сложности. В задачу алгоритма кластеризации сходит непосредственно распределение объектов данных между кластерами 112

Труды конференции Телематика’2010

разделением больших кластеров, объединением малых или перераспределением объектов между кластерами, не меняя их количество. Наиболее популярными и простыми алгоритмами кластеризации является иерархический алгоритм ближайшего соседа и неиерархический k-means [7]. K-means – один из самых простых с точки зрения вычислительной сложности алгоритмов, также его достоинством является простота восприятия процесса и результата человеком. Однако данный алгоритм имеет серьезный недостаток: набор объектов данных должен четко разбиваться на кластеры. Предъявить такое требование к объектам векторной модели текстовых документов нельзя. Еще одним недостатком является чувствительность алгоритма к выбросам данных. То есть один или несколько объектов данных, имеющих слишком отличающиеся от средних значения некоторых характеристик, сильно сдвигают центроид в свою сторону и делают представление о кластере в целом искаженным. Также имеется недостаток на стадии подготовки данных для кластеризации алгоритмом k-means. Суть его в случайном распределении объектов по заданному количеству кластеров. Этот процесс иногда может способствовать увеличению скорости кластеризации, но вероятность этого уменьшается с возрастанием количества объектов в наборе. Таким образом, при большом наборе этот процесс, занимая некоторое время, не способствует уменьшению времени кластеризации. Иерархическим алгоритмам не требуется предварительное случайное распределение объектов по кластерам. При использовании подкласса агломеративных алгоритмов, к которому относится алгоритм ближайшего соседа, на стадии подготовки каждый объект данных имеет свой кластер. Составляется матрица попарной близости кластеров. Впоследствии, при каждой итерации цикла кластеризации наиболее похожие на основании матрицы соседства кластеры объединяются в один. Недостатком алгоритма является иногда сложный перерасчет атрибутов новых кластеров, так как для этого необходимо заново вычислять попарную близость имеющихся кластеров с новым с помощью выбранной функции меры близости. Алгоритм ближайшего соседа также имеет те же недостатки, что и k-means, предъявляя требование четкого разделения к набору данных и являясь чувствительным к выбросам данных. Используемый в реализации алгоритм ROCK (Robust Clustering using Links) [8] является иерархическим агломеративным алгоритмом, сочетающим в себе достоинства k-means и алгоритма ближайшего соседа, а также решающий их описанные выше недостатки. Основная идея алгоритма заключается во введении каждой паре объектов нового параметра – количество общих соседей (ссылок). Этот параметр получается из матрицы соседства путем выяснения в цикле по каждому объекту, является ли он соседями двух рассматриваемых. Благодаря учету ссылок алгоритм становится нечувствительным к выбросам и не требует четкого разделения объектов на кластеры. Также работая в цикле кластеризации со ссылками, объединяя кластеры, легко получить новые значения параметров ссылок с другими кластерами: для этого достаточно сложить соответствующие значения параметра ссылок двух объединяемых кластеров. Алгоритм был разработан для кластеризации объектов данных с большим количеством числовых и номинальных атрибутов. Типичными задачами кластеризации алгоритмом ROCK является прогнозирование свойств сложных объектов по неполным наборам атрибутов у некоторых из них. Похожими свойствами обладают и объекты в задаче данной работы. Так как не во всех статьях есть все слова, встречающиеся в данном наборе, то при сравнении параметров двух объектов атрибут, отвечающий за частоту употребления определенного слова, можно рассматривать как булевый (то есть частный случай номинального): «встречается» или «не встречается». Таких атрибутов при попарном сравнении будет достаточно много. Оставшиеся атрибуты, имеющиеся у обоих рассматриваемых объектов, сравниваются как числовые. Такой набор атрибутов удовлетворяет требованиям для кластеризации алгоритмом ROCK. При всех своих достоинствах и решении проблем предшественников алгоритм ROCK имеет один серьезный недостаток: увеличение вычислительной сложности. Процесс подсчета ссылок является самым долгим во всей кластеризации. Однако, следует заметить, что подсчет ссылок происходит лишь один раз на этапе подготовки данных, процесс кластеризации занимает значительно меньше времени. В данной работе имеются некоторые средства оптимизации процесса вычисления ссылок, а одним из ключевых направлений дальнейшей разработки является аппроксимация матриц соседства и ссылок, которая позволит значительно уменьшить время вычислений. Теперь подробнее рассмотрим выбор метрики близости двух объектов данных. Во всех описанных выше алгоритмах для начала нужно выбрать функцию, которая по атрибутам объектов определяет степень их соседства. Одной из популярных функций для сравнения объектов является Евклидово расстояние. Чтобы с помощью нее узнать, насколько два объекта близки, нужно сложить квадраты разности значений соответствующих атрибутов и взять корень. Эта метрика имеет ряд недостатков при использовании в данной задаче. Главным недостатком этой метрики является неправильный учет атрибутов, отсутствующих у одного объекта и имеющихся у другого. Например, есть три объекта данных, представленных в виде следующих векторов:

A = (1,0,0,0,0) 

B = (0,0,0,0,1) 

C = (1,1,1,1,0)

Вычислив Евклидово расстояние, получаем:

|A‐B|=

 

|A‐C|=

 

|B‐C|= 113

Хотя объекты А и В не имеют общих атрибутов, по данной метрике они ближе чем объекты А и С. Более правдоподобно мера близости двух объектов будет выглядеть, если использовать коэффициент Жаккарда [9]. Он считается значительно проще Евклидового расстояния. Чтобы вычислить по нему схожесть двух объектов, нужно представить все их атрибуты как точки двух множеств. Эти множества пересекаются в точках, где объекты имеют общие атрибуты. Коэффициент Жаккарда это отношение пересечения данных множеств к их объединению. В случае, когда у обоих объектов имеется атрибут с разными значениями, в числитель прибавляется меньшее из двух, а в знаменатель сумма значений этого атрибута. Для выше описанного примера:

sim(A,B)=0 

sim(A,C)=1/5 

sim(B,C)=0

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

Подсчет количества прогнозируемых ссылок – одна из наиболее важных задач при работе с алгоритмом ROCK. Так как количество ссылок изначально зависит от порогового коэффициента при определении соседей среди объектов набора, размеров кластеров (а вернее от размеров объектов в нем), эти два параметра являются входными данными функции прогнозирования количества ссылок. Также нужна функция такая, что точка, принадлежащая к кластеру размером n, будет иметь кластере, где

θ

в

– пороговый коэффициент соседства. Одной из наиболее простых и удачных таких

функций является

. Итоговая функция меры близости будет выглядеть так:

Полученная форума и есть итоговая мера близости, используемая в алгоритме ROCK. Практическая часть Работа программы кластеризации начинается с загрузки данных, полученных из программы подготовки текста. Загрузка производится из двух таблиц: моделей основного текста и моделей заголовков. На странице администрирования кластеризации можно регулировать коэффициент значимости термов в заголовках при определении тематики текста. Также на этом этапе для каждого объекта данных создается свой одиночный кластер, размер которого совпадает с размером объекта данных, который он содержит. Финальным этапом загрузки является составление модели для каждого документа с учетом веса заголовков. На следующем этапе происходит выявление соседства объектов данных по правилам, описанным выше. Этот процесс занимает небольшую часть от общего времени кластеризации. Для экономии места и увеличения скорости работы программы матрица соседства записывается в виде списка для каждого объекта данных, содержащего только соседей с бóльшим порядковым номером. На следующем этапе подготовки к кластеризации происходит вычисление количества общих соседей для каждого объекта, имеющего хотя бы одного соседа. Как было замечено выше, этот процесс имеет наибольшую вычислительную сложность во всем процессе кластеризации – O(3N). Однако, при увеличении порогового коэффициента определяющего соседство, можно значительно уменьшить время работы этого процесса. Затем для каждой пары объектов, имеющих хотя бы одного общего соседа, вычисляется мера близости g. На этом этап подготовки данных завершается. Далее начинается цикл кластеризации, в каждой итерации которого сливаются в один кластеры с наибольшим значением g. На каждой итерации также происходит проверка условий выхода из цикла. Основным условием выхода является отсутствие ненулевых связей между кластерами. Также 114

Труды конференции Телематика’2010

пользователь через страницу администрирования кластеризации может задать дополнительные условия выхода, а именно: количество проведенных итераций, общее количество полученных кластеров и получение кластера заданного размера. После выбора двух кластеров с наиболее сильной связью происходит формирование нового кластера, который содержит объекты данных двух сливаемых. Затем происходит подсчет количества общих соседей нового кластера с другими. Для этого достаточно сложить соответствующие значения сливаемых кластеров и вставить их как количество ссылок с новым. Затем значения ссылок со сливаемыми кластерами удаляются из матрицы ссылок. Далее происходит вычисление g для нового кластера и всех других. После этого новый кластер имеет все необходимые параметры. Вся информация о слитых кластерах окончательно удаляется из памяти. После выхода из цикла кластеризации происходит формирование отчета с результатами. В базе данных обновляется таблица с индексом статей, куда заносится принадлежность к определенному кластеру. Список кластеров затем доступен на странице статистики расширения MediaWiki. Результаты работы При задании различных коэффициентов соседства можно использовать данное расширение в кафедральной базе знаний для следующих целей: поиск одинаковых статей, поиск похожих отчетов по различным работам, поиск материалов по определенной дисциплине и поиск материалов, смежных для нескольких дисциплин. Наиболее востребованными являются задачи поиска похожих отчетов (востребовано студентами, использующими отчеты в качестве примера) и поиск смежных материалов различных дисциплин для последующего учета уже имеющихся у студентов знаний. На данный момент разработка имеет некоторые погрешности при выполнении последней задачи, однако достаточно хорошо справляется с остальными. Скорость работы во многом зависит от настроек программ, но с наиболее стандартными параметрами для 1500 статей при 128 Мб оперативной памяти: подготовка текста занимает 15–20 минут, кластеризация 20-25 минут. При этом большую часть времени кластеризации занимает подготовка данных (построение матрицы ссылок), работа же цикла кластеризации занимает 5–7 минут с условием работы, пока есть ненулевые связи. Эффективность алгоритма во многом зависит от формулы предсказания количества ссылок. Получение наиболее точной формулы и является основной задачей дальнейших исследований модели. Одним из важных направлений также является улучшение нормализации текстовых документов, оптимизация и улучшение качества стемминга. Также направлениями дальнейших разработок являются: учет сложных текстовых конструкций (формул, кода программ), аппроксимация матриц для уменьшения времени подготовки к кластеризации. Литература 1. John F. Gantz "A Forecast of Worldwide Information Growth Through 2010" The Expanding Digital Universe, 2007. 2. Schacht P. "The Collaborative Writing Project", "Using Wiki in Education", 2007. 3. Cao G., Song D., Bruza P. "Suffix Tree Clustering on Post-retrieval Documents Information." The University of Queensland, 2003. 4. G. Salton, A. Wong, and C. S. Yang, "A Vector Space Model for Automatic Indexing," Communications of the ACM, – 1975 – T. 18. – № 11. – C. 613–620. 5. Codd, E.F. "Further Normalization of the Data Base Relational Model." Courant Computer Science Symposia Series 6, "Data Base Systems," New York City, 1971. 6. M.F. Porter "An algorithm for suffix stripping" Program. – 1980. – Т. 14. – № 3. – С. 130–137. 7. MacQueen, J. B. "Some Methods for classification and Analysis of Multivariate Observations". 1. Proceedings of 5th Berkeley Symposium on Mathematical Statistics and Probability. University of California Press. 1967 – C. 281–297. 8. Sudipto G., Rajeev R., Kyuseok S. "ROCK: A Robust Clustering Algorithm for Categorical Attributes", KAIST, 2000. 9. Paul Jaccard "Étude comparative de la distribution florale dans une portion des Alpes et des Jura" Bulletin de la Société Vaudoise des Sciences Naturelles. – 1901 – C. 547–579.

СИСТЕМА ПРОФЕССИОНАЛЬНОГО ОРИЕНТИРОВАНИЯ АБИТУРИЕНТА КАК МОДУЛЬ ОБРАЗОВАТЕЛЬНОГО ПОРТАЛА ВУЗА Д.О. Федоров, В.А Ипатова, Я.Ю. Петунин Московский государственный институт радиотехники, электроники и автоматики (технический университет) E-mail: [email protected] Ухудшение демографической ситуации в стране привело к резкому снижению количества поступающих в высшие учебные заведения. Следствием этого, стало обострение «борьбы за 115

абитуриента» между образовательными учреждениями, предлагающими близкий набор услуг и образовательных программ. В связи с этим пришло понимание, что главным достоянием любого учебного заведения является учащийся и для того, чтобы абитуриент пришел в вуз, необходимо выстраивать отношения с ним на основе его же предпочтений и целей, предлагая образовательные услуги и программы, наиболее интересные и полезные конкретному человеку. Актуальность работы определяется потребностью в разработке программного модуля, позволяющего поддержать индивидуальные траектории обучения, строящиеся непосредственно в процессе контактов абитуриента и учебного заведения, позволяющего учитывать в первую очередь интересы абитуриента, а не только интересы вуза. Данный подход к потребителю, в нашем случае образовательных услуг, носит название клиентоориентированного. Существует целый класс информационных систем, использующихся преимущественно в экономике, позволяющих обеспечивать поддержку клиенто-ориентированного подхода. Это системы управления взаимоотношениями с клиентами или CRM-системы. В области образования программные продукты подобного рода обеспечивают либо финансовую составляющую общения с абитуриентом, либо, чаще всего, это системы дистанционного обучения. В большинстве систем дистанционного обучения есть средства поддержки траекторий, учитывающих компетенции слушателя, но граница ответственности данных средств не выходит за четко заданные рамки образовательного процесса. Анализируя существующие программные продукты, для выбора технологии построения системы профессионального ориентирования абитуриента вуза, были рассмотрены архитектуры CRM-систем и существующие информационные системы вузов. В ходе работы были сделаны следующие выводы: • Практически у каждого вуза имеется свой сайт или интернет-портал. • Модульность – разрабатываемое приложение должно иметь возможность встраиваться в существующие продукты и соответственно должно быть реализовано как отдельный программный модуль или узел. • Минимальные вложения. Большинство платформ для создания CRM-решений дорогостоящие, а в нашем случае необходима минимизация затрат. • Необходимость отсутствия территориальных ограничений. • Нет необходимости в синхронизации offline-клиента при очередном появлении его в сети. Таким образом, считаем, что наиболее целесообразно производить построение системы профессионального ориентирования абитуриента учебного заведения на основе интернет-технологий, а именно портальных технологий, удовлетворяющим всем вышеперечисленным требованиям и не нуждающихся в приобретении дополнительных лицензий на приобретение программного обеспечения, так как все программное обеспечение физически находится на одном сервере (возможно даже виртуальном). Последнее соображение явилось одним из определяющих при выборе в качестве платформы разработки системы Windows SharePoint Services 3.0, так как в ней поддерживается интеграция с документами Microsoft Office и не требуется дополнительных лицензий для ее установки. Предполагается следующий порядок выстраивания отношений с абитуриентом. На первоначальном этапе система должна определить, какая специальность наиболее соответствует компетенциям и предпочтениям абитуриент. Для этого разработан классификатор специальностей, в котором каждой специальности соответствует набор требований

H = ( h1 ,..., hn ) ,

на основе которых будет

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

F ( L) = H или lim f (li ) = hi .

L = (l1 ,..., ln ) . В результате

t →T

Процесс работы пользователя с системой профессионального ориентирования абитуриента, выполненной на основе портальных технологий, представлен на рис. 1. После регистрации абитуриента в системе составляется профиль пользователя, собираются и аккумулируются в едином хранилище данные об абитуриенте, его предпочтениях и компетенциях, на основе «Калькулятора специальностей» подбирается наиболее интересная для него специальность или направление обучения. По результатам опросов и на основе анализа ссылок, которыми воспользовался пользователь во время своего посещения сайта, выясняется наиболее предпочтительный вариант дальнейшего общения и взаимодействия. Хочется подчеркнуть, что так же в системе накапливается и сохраняется вся история взаимоотношения с абитуриентом от посещения сайта, до личной встречи с представителями вуза (членами приемной комиссии, преподавателями, выпускниками и т.п.) по результатам анализа которой также выясняются предпочтения абитуриента. Для корректного описания на языке математики процесса выстраивания взаимоотношений с абитуриентом построена модель пользователя системы.

116

Труды конференции Телематика’2010

Рис. 1. Схема работы абитуриента с системой профессионального ориентирования абитуриента Моделью пользователя будем называть преобразование Fn, определяющее рекуррентно состояние пользователя в текущий и предыдущий момент времени по параметрам Pn, Un,, С и Hn , где: • С – вектор неизменяемых параметров клиента (например, личностные характеристики человека); • Hn – вектор динамических параметров абитуриента в момент времени tn, в который так же входят степень заинтересованности пользователя, коэффициент лояльности, личные цели обучаемого, компетентность в конкретной области и т.д.); • Pn – состояние в момент времени tn, определяемое вектором неизменяемых параметров клиента С и вектором динамических параметров Hn; • U – управление. То есть состояние субъекта в момент времени tn+1 будет описываться формулой: (1) Для выработки оптимального управления среди параметров модели необходимо учесть процесс забывания (на основании данных психологических исследований рассматривается экспоненциальная зависимость), так как этот параметр будет использоваться при выборе временного интервала взаимодействия (промежуток времени, после которого необходимо произвести очередной сеанс управления (телефонный звонок, рассылка по электронной почте, личная встреча и т.п.). При выстраивании персонифицированного общения и повышения лояльности абитуриента в процессе профориентирования необходимо учитывать личные цели, которые описаны набором динамических и статических параметров:

P*ind = {C, H*ind}

(2)

Для того чтобы полученная модель была адекватна реальным значениям, на каждом шаге управления необходимо корректировать параметры Hn и Fn, а также вносить уточнения в личные цели пользователя P*ind., поскольку зачастую абитуриент не обладает достаточной информацией для самостоятельного определения будущей специальности, а опирается в своем выборе на субъективное мнение знакомых и родственников. Математическая интерпретация метода управления по целям Процесс выстраивания взаимоотношений с абитуриентом представляется в виде последовательности сеансов взаимодействия в общем случае не равноотстоящих друг от друга, и начинающихся в момент первого обращения пользователя к системе. Таким образом, задача сводится к задаче синтеза эффективного управления U, которое переводит обучаемого из начального состояния Р0 * в заранее заданное «идеальное» (или целевое) состояние Р . При выстраивании процесса управления наибольший эффект от управления будет достигаться при совпадении (или частичном совпадении) личных целей абитуриента и наших текущих целей, то есть P*=P*ind . Процесс управления в этом случае не требователен к ресурсам и будет сводиться к периодическому мониторингу текущего состояния пользователя, а также, при необходимости, к консультированию по возникающим вопросам. В противном случае процесс управления будет состоять из последовательности итерационных воздействий, ограниченных в ресурсах и по времени. Так как мы имеем дело с последовательностью воздействий, то будем считать процесс управления дискретным во времени. Для оценки эффективности управления на каждом шаге была введена функция качества Kn, зависящая от «удаленности» текущего состояния объекта управления от целевого («эталонного») 117

состояния в момент времени tn. Процесс управления будет считаться завершенным, когда коэффициент качества управления Kn достигнет определенного, заранее заданного значения, или значение времени превысит критическое значении Tкр, т.е.

tn > Tкр

(3)

В последнем случае процесс управления будет завершаться неудачей, поскольку дальнейшее управление теряет всякий смысл, а конкретная цель считается не достигнутой. После этого в системе производится анализ дальнейшего продолжения выстраивания и поддержки отношений с абитуриентом и либо формируется новая цель и новый процесс управления, либо профиль абитуриента отправляется в архив. В свою очередь процесс управления рассматривается на множестве пронумерованных элементарных воздействий. Для каждого пользователя на основе анализа истории взаимоотношений с ним строится таблица воздействий, в которой будет содержаться тип воздействия и среднее время реакции пользователя на него (табл. 1). Таблица 1. Пример «таблицы воздействий» Пользователя 1 Воздействие Почтовая рассылка Телефонный звонок Личная беседа Личное письмо Маркетинговая акция

Время реакции 7 дней 3 часа Мгновенно 2 дня –

На каждом шаге с помощью определенного алгоритма строится подмножество из множества воздействий Mn. Воздействия подбираются таким образом, чтобы за минимальное число шагов с учетом ограничений по времени и ресурсам достигнуть поставленной цели. Для построения надежного управления на каждом шаге взаимодействия с пользователем была введена функция качества K, которая постоянно уточняется для каждого пользователя, то есть необходимо решить задачу оптимизации: (4) где • O(L) – множество воздействий из Mn, удовлетворяющих ресурсу L; • Ln – ресурс, выделенный на n-ый шаг обучения (финансовое, временное ограничение, наличие консультанта и т.п.); • U*n – локально-оптимальный набор воздействий, приходящийся на n-ый шаг. Для расчета критерия качества управления в данной работе использованы формулы (5), (6), так как подобный вариант наиболее прост при компьютерной реализации и позволяет производить мониторинг по каждому из параметров пользователя. Таким образом, в качестве критерия качества управления используется вектор Kn, по размерности совпадающий с количеством параметров в профиле пользователя, характеризующих текущее состояние субъекта:

Kn = (k1,k2, … kJ) где

(5) , 0< j<J,

(6)

J – размерность состояния, которая определяется совокупностью всех статических и динамических параметров пользователя:

Pn = (p1, p2, … pJ)

(7)

Таким образом, в системе происходит перерасчет показателей, вычисляется время до ближайшей опорной точки – время, в течение которого есть смысл производить взаимодействие с абитуриентом (например, дата вступительного экзамена), рассчитывается лояльность клиента и т.п. Совместный анализ изменений критерия качества управления Kn и набора управляющих воздействий Un позволяет подобрать наиболее эффективное управление взаимоотношением с абитуриентом, с учетом индивидуальных компетенций и предпочтений каждого абитуриента. Такой анализ, опирающийся на личные предпочтения человека, позволит на порядок повысить заинтересованность абитуриента в поступлении именно в наш вуз, и, как следствие, положительно скажется на последующем образовательном процессе, повысив мотивированность учащихся и сократив отсев. 118

Труды конференции Телематика’2010

Также при выделении некой глобальной цели (к примеру, план поступления по специальностям), возможен анализ текущего состояния системы в целом и предложение мероприятий, нацеленных на достижение данной цели по аналогии с маркетинговыми акциями в CRM-системах. Архитектура системы профессионального ориентирования абитуриента в самом общем случае показана на рис. 2.

Легенда Подзаголовок легенды Символ

Описание Веб-сервер Сервер электронной почты Сервер баз данных Сервер приложений Прокси-сервер Переносной компьютер ПК

Рис. 2. Архитектура решения системы профессионального ориентирования абитуриента В заключение, хочется отдельно остановиться на плюсах выбора портальных технологий для построения системы профессионального ориентирования абитуриента с точки зрения схожести архитектуры CRM-систем и портальных технологий. Слой безопасности. Слой безопасности автоматически интегрирован со слоем доступа к данным. Отвечает за них СУБД и средства безопасности Web-сервера (Internet Information Services). Интеграция со Службой каталогов Windows (Active Directory) или аналогичными сервисами, в зависимости от платформы, на которой развернут портал и операционной системы сервера) позволяют производить сквозную авторизацию операционная система–портал–приложение. Слой интерфейсов. Так как разрабатываемый модуль CRM проектируется, как модуль корпоративного портала, то слой интерфейса автоматически будет «наследоваться» с портала, что позволит избежать проблем с переучиванием персонала на другой интерфейс. Слой функциональных сервисов. Часть сервисов уже существует в портале (например, отправка сообщений, календари и сервис оповещений), часть можно позаимствовать из СУБД (для анализа данных удобнее всего строить так называемые OLAP-кубы, а это больше относится к службам СУБД), а часть сервисов можно разработать самостоятельно. Если развивать идеи eCRM (Интернет-ориентированных СRM-систем), то в контексте портальных технологий целесообразно в дальнейшем использовать экстранет-порталы – защищенную от несанкционированного доступа корпоративную сеть, использующую Интернет-технологии для внутрикорпоративных целей, так как в этом случае не возникает особых проблем с защитой информации. Результаты: • Определена актуальность разработки клиенто-ориентированных методов профессионального ориентирования абитуриентов высших учебных заведений в условиях современного демографического кризиса. • Выполнен анализ современных клиенто-ориентированных систем и образовательных информационных систем учебных заведений в целях выбора наиболее оптимальной архитектуры 119

системы профессионального ориентирования абитуриентов, а именно CRM-подобной системы, базирующейся на портальных технологиях. • Разработана математическая модель пользователя, учитывающая личные предпочтения, компетенции и навыки абитуриента. • Разработан алгоритм выстраивания взаимоотношений с абитуриентом с расчетом лояльности к образовательному учреждению. • Внедрен метод «управления по целям», учитывающий локальные цели и пожелания каждого абитуриента Реализован «Калькулятор абитуриента» как версия системы профессионального ориентирования абитуриентов. Представленная система разработана и проходит тестирование на факультете информационных технологий МИРЭА. Перспективы: система далее будет развиваться, как система непрерывного обучения, и включать в себя весь процесс обучения студента, с момента поступления. Также работа такой системы приведёт к организации различных курсов и дисциплин, интересных для предпринимателей и бизнеса на базе вуза, что позволит давать образование, отвечающее требованиям бизнеса, повысит капитализацию и конкурентоспособность вуза. Литература 1.

2. 3.

4. 5.

Андрианова Е.Г., Чаплыгин А.Н. «Повышение качества обучения за счет применения концепций CRM и социальных сетей при организации дистанционного учебного процесса», НТК МИРЭА, 2006, ч. 4, С. 34-40. Петунин Я.Ю. «Математическая модель управления взаимоотношениями с клиентами», Труды института системного анализа РАН, том 42 (1), 2009, С. 252-254. Герасимов В.В., Курмышев Н.В. «От университетского сайта к порталу, что за этим скрывается?», Новгородский государственный университет им. Ярослава Мудрого, Великий Новгород. Информационный ресурс для разработчиков CRM-систем http://searchcrm.techtarget.com/. Т. Паттисон, Д. Ларсон. Внутреннее устройство Microsoft Windows SharePoint Services 3.0. Санкт-Петербург: Издательский дом «Питер», 2008.

ПОДХОД К ПРОБЛЕМЕ ВЫБОРА ФОРМЫ УПРАВЛЕНИЯ ИТ В ПРЕДПРИЯТИЯХ МАЛОГО И СРЕДНЕГО БИЗНЕСА А.С. Силенин Московский государственный институт электроники и математики (технический университет) E-mail: [email protected] Д.А. Медведев: «...в период кризиса такой один из самых важнейших кластеров, одно из самых важнейших направлений работы – это малый бизнес. Потому что если малый бизнес исчезнет в пучине кризиса, нам придётся восстанавливаться не годы, а десятилетия. И от того, какой мы климат создадим сейчас для малого бизнеса, зависит и быстрота нашего выхода из кризисного пике» [1]. Любое современное предприятие существует, используя ИТ-технологии. ИТ сегодня – это автоматизация, которая позволяет предприятию быть конкурентоспособным. Формула владения ИТ проста: • работает то, что управляется; • управляется то, что контролируемо; • контролируемо то, что автоматизировано. Крупный бизнес давно осознал проблемы, связанные с владением ИТ-технологий. Рынок буквально завален предложениями в сфере ИТ. У всех этих решений есть только одна отрицательная сторона. Для крупных предприятий стоимость вкупе с получаемым эффектом дает крупным предприятиям инструмент принятия решения – выбора стратегии развития собственного ИТ. Но как быть предприятиям малого и среднего бизнеса (той части, которая близка к малым)? Для них стоимость одного из десятка необходимых решений может быть близка к стоимости всего бизнеса. Кроме конкретных, продаваемых решений в мире есть и теоретические наработки: • ITIL; • Cobit; • и пр. Но все эти наработки рассчитаны были изначально для предприятий крупного бизнеса. Специалисты скептически относятся к идее применения выше перечисленных методик для организации ИТ в малых и средних предприятиях. А ведь решать вопросы ИТ предприятиям нужно уже сегодня. 120

Труды конференции Телематика’2010

Некоторые предприятия стараются отложить принятие решений о судьбе ИТ «до лучших времен», пытаясь обойтись временными решениями. Но, как известно «скупой платит дважды». В итоге стоимость владения ИТ для такого предприятия будет в разы больше, в отличие от исхода, при котором был бы выбран конкретный путь развития. Первый вопрос, который нужно решить – это способ управления ИТ на предприятии: • собственный ИТ-отдел; • аутсорсинг ИТ. Для начала разберемся, какое оно – предприятие малого или среднего бизнеса: из каких бизнеспроцессов оно состоит и что в нем обеспечено поддержкой ИТ. В контексте данной статьи главным критерием, определяющим целевое предприятие, является численность сотрудников – приблизительно 50 человек. По роду деятельности это могут быть предприятия, работающие в сферах: • торговля товарами: оборудование, техника; бытовая электроника и техника; бытовые и хозяйственные товары; компьютеры и оргтехника, товары для офиса; мебель; магазины, предприятия торговли и питания; одежда, обувь, белье, ткани, ковры; продовольственные товары; сырье и материалы; • предоставление услуг: образование и наука; бытовые услуги, досуг; медицина и здравоохранение; общественные организации, религия; производственные услуги; спорт; строительство; транспорт; туризм, гостиницы; юридические и бухгалтерские услуги, недвижимость, реклама и пр.; • унитарные предприятия: органы власти, управления и ведомства; природные хозяйства; жилищнокоммунальное хозяйство; культура; • предприятия, связанные с ИТ: информация, СМИ; провайдеры коммуникационных услуг; провайдеры ИТ-услуг (обслуживание ИТ или узлов ИТ). Если рассматривать бизнес-процессы на предприятии, то из них можно выделить, во-первых, базовые – обеспечивающие нормальное функционирование предприятия во взаимоотношениях с внешними и внутренними контрагентами (сотрудники, клиенты, партнеры). Они также включают в себя обязательные для любого предприятия процессы. Во-вторых, есть специфичные для конкретного предприятия процессы, которые обеспечивают достижение цели, на которую нацелено предприятие (в общем случае это получение дохода). Базовые бизнес-процессы также можно разделить по отношению к клиенту: back-office; front office. К первым относятся: • все формы бухгалтерского учета и бухгалтерская отчетность; • управленческий учет; • кадровый учет; • юридический отдел; • ИТ отдел. К front-office относятся: • работа с клиентами; • работа с партнерами и поставщиками; • маркетинг. Отличие предприятий друг от друга лежит в бизнес-процессе, который можно назвать производство. Он может состоять из нескольких бизнес-процессов. При этом возможно, что предприятие является поставщиком услуги одного из перечисленных бизнес-процессов. И этот же, базовый для других, но являющийся производством для себя, является также базовым для самого предприятия. Как правило, в таких случаях производство воспринимает родную компанию как одного из клиентов, которому также предоставляется данная услуга. С другой стороны, любой из перечисленных базовых бизнес-процессов может осуществляться силами наемных компаний, т.е. отдан на аутсорсинг. Одним из ключевых свойств работы базовых сервисов должно являться его надежность. Ведь базовые сервисы являют собой платформу, на которую положены основные, ключевые сервисы. Любой сбой в базовой платформе могут привести к простою или потере ресурса у ключевых. ИТ отдел играет особую роль в жизнедеятельности предприятия. Во-первых, он обслуживает текущую ИТ-инфраструктуру предприятия. С другой стороны ИТ-отдел должен отслеживать и вовремя замечать области, которые несут в себе риски и требуют особого внимания. Эти процессы для нормального функционирования требуют наличия высококвалифицированных специалистов и, что особо важно, они должны гарантировать надежность выполняемых действий. Как правило, специалисты высокого уровня характеризуются высокой стоимостью работ, что для предприятий малого и среднего бизнеса может быть недоступно. Но даже если финансовая возможность обладания ценным кадровым ресурсом есть, еще реже предприятия способны обеспечить оптимальную загруженность для таких специалистов. Это означает, что ресурс используется не оптимально. Есть еще и третий фактор – обсуждаемый ресурс, это люди, а они подвержены многим факторам, способным привести его в не рабочее состояние – начиная от болезни, заканчивая отпуском. Если представить, что этот ресурс необходимо резервировать, то получается, что все описанные сложности, связанные с обладанием этим ресурсом, автоматически множатся. 121

Также не стоит забывать об управляемости ИТ-отдела. ИТ-отдел должен быть прозрачным для руководства компании. «Непонятный» ИТ представляет собой невероятный риск – начиная с непонимания, на что тратятся средства, что в свою очередь приводит к неуправляемости финансирования ИТ, и заканчивая возможностью утечки информации, что для иного предприятия может стать губительным фактором. С другой стороны ИТ-отдел должен быть готов к любым изменениям в компании. Любой виток роста и развития предприятия напрямую будет зависеть от реакции и готовности ИТ-отдела. Сможет ли небольшое предприятие обеспечить себя достаточно квалифицированными специалистами, способными решать такие задачи? При этом, опять же, не стоит забывать о рисках. Ошибка в выборе достойного поставщика ИТ-услуг может стоить небольшому предприятию большего, чем крупному, если соизмерить с объемом бизнеса. Неверно выбранный партнер не сможет качественно выполнить свою работу, что в свою очередь может привести к провалу всего объема мероприятий, которые могли бы дать предприятию конкурентное преимущество. Такая неудача может закончиться даже закрытием предприятия: например, если расходы на развитие будут завышены, а отдачи от нововведений не будет из-за неудачного исполнения. В завершение стоит упомянуть одну из наиболее существенных ИТ-ролей: ИТ-аудит. Для того чтобы быть уверенным в будущем своей компании, нужно быть уверенным в том, на чем держится компания. Мы уже увидели, что ИТ в компании играет не самую последнюю роль. Принято считать, что у ИТ-специалистов свой собственный язык общения. Понять, что происходит в ИТ предприятия не всегда возможно управляющему предприятием. У него свой язык – язык бизнеса и денег. Для того чтобы ожидания управляющего соответствовали результатам, которые дает ИТ, необходимо производить плановые и специальные аудит-проверки. Они позволят выявить возможные риски, а также укажут, на что нужно обратить внимание дабы гарантировать намеченный результат. Выбор формы ИТ-отдела Итак, мы подошли к главному – в какой форме должен существовать ИТ-отдел в предприятии. Фактически выбор состоит из двух вариантов: собственный ИТ-отдел или же передача ИТ на внешнее исполнение. Единственное, что влияет на принятие решения – это мнение владельца бизнеса. И только на него есть возможность влиять. Стоит понимать, что ответственность за принятое решение может быть ответственен только владелец предприятия – от его своевременных и верных решений зависит благополучие предприятия. А что может учесть при принятии решения владелец? Во-первых, определяющим фактором может стать невозможность допуска сторонних лиц к данным компании. Зачастую этот фактор переоценен. Определить его можно только сопоставив реальные цифры – расходы на обслуживание ИТ. В этом случае нужно задаться вопросом – а есть ли у компании возможность владеть собственным ИТотделом? Любой из исходов может быть выгоден компании. Разберемся – почему? В случае, если компания не может позволить себе владеть собственным ИТ-отделом, то есть два варианта развития. Первый – переход на аутсорсинговое обслуживание. В этом случае, при должном внимании и не полном отчуждении ответственности за ИТ стороннему поставщику компания может получить мощный, измеримый инструмент, который, как и было обещано, может дать заветное конкурентное преимущество. Второй – отказ от новых возможностей и найм «временного» собственного «системного администратора». В этом случае компания подвергает себя огромному риску, но при этом сохраняет возможность своего дальнейшего существования. В случае же, если компания осознает истинную необходимость во владении собственным ИТотделом – то наступает переходный период. Собственный ИТ-отдел требует собственного ИТруководителя. И пройдет время, прежде чем ИТ-отдел «созреет» и сможет дать компании то, для чего он был создан. В этом случае ИТ-отдел изначально создается как убыточное подразделение компании. На протяжении всего времени его существования он будет бороться с этим ярлыком. Сразу после рождения этот отдел будет экстра убыточным. В худшем случае этот отдел, преодолев стадию взросления, получится неповоротливым, непрозрачным и ненавистным руководством компании. Но это лишь негативный исход. На сегодняшний день эксперты в области управления ИТ предлагают другой вариант развития. ИТ-отдел, который был с должным вниманием выращен, может с легкостью вернуть все затраченные на него средства. Во-первых, рост ИТ может повлечь за собой уверенный рост всей компании. И отдел, который создавался для обслуживания, скажем, пятидесяти рабочих мест превратится в ИТпредприятие, обслуживающее десятки таких предприятий или офисов. Есть и другой вариант. Не каждое предприятие может быть подвергнуто такому росту. Но прелесть небольших предприятий в их простоте с точки зрения ИТ. Отличия между предприятиями в одной области могут быть минимальными. В этом случае этот ИТ-отдел может начать продавать свои услуги аналогичным предприятиям, возвращая материнской компании все вложения. И если приглядеться внимательно ко всем позитивным исходам, то мы увидим, что фактически это отражение аутсорсинга. И, возможно, для такого ИТ-отдела это будет следующим витком развития.

122

Труды конференции Телематика’2010

Заключение Вне зависимости от выбора формы ИТ-отдела ИТ-инфраструктуру любой компании необходимо обслуживать. Как и любая другая техника ИТ-инфраструктура компании будет давать сбои. Которые необходимо устранять. Любой сбой является ударом по работе предприятия. Какой же урон принесет такой удар – зависит от заранее предпринятых мер. Или речь может идти о полученном уроке и выводах, которые сделает руководитель бизнеса, который смог вытянуть компанию из возникшей ситуации. Для тех же, кто не до конца осознает, какое место в компании занимает ИТ, стоит привести график, который продемонстрировал исполнительный вице-президент «Вымпелком» в своем выступлении на конференции «Платформа» в 2008 году, в разгар кризиса (рис. 1) [2]. ИТ должно быть организовано так, чтобы любой сбой мог быть локализован в максимально сжатые сроки. При этом стоит помнить и понимать, что ИТ нужно рассматривать как статичный процесс, который нужно поддерживать. ИТ также должно нести упреждающий характер. ИТ существует в своем непрерывном развитии. И при грамотном использовании способно стать инструментом, представляющим возможности получения преимущества, выполняя роль подсказчика. Литература 1. http://vmeste.edinros.ru/analytics/analytics_977.html. 2. Презентация финального доклада на конференции «Платформа 2009».

Рис. 1. Слайд с финального выступления Н. Прянишникова на конференции «Платформа 2009»

АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА СОПРОВОЖДЕНИЯ ДОВУЗОВСКОЙ ПОДГОТОВКИ УЧАЩИХСЯ А.В. Соловьева, Ю.А. Соловьева Сибирский государственный индустриальный университет, г. Новокузнецк E-mail: [email protected] Создание систем эффективного управления организациями самого разного характера и сферы деятельности – одна из проблем, стоящих перед современным динамичным менеджментом. В число наиболее передовых методов построения систем эффективного управления входит так называемый процессный подход к управлению. Последний заключается в выделении в организации сети процессов и управлении этими процессами для достижения максимальной эффективности деятельности организации [1]. 123

СибГИУ – один из крупнейших университетов Сибири. Он осуществляет обучение студентов по 63 специальностям и 14 направлениям подготовки специалистов. Факультет довузовской подготовки является структурным подразделением СибГИУ, которое организует работу с учащимися образовательных, начальных и средних профессиональных учреждений по следующим направлениям (рис. 1): • образовательная подготовка; • профориентация; • методическая работа; • научно-исследовательская работа сотрудников факультета.

Образовательная подготовка • • • • • • •

Профориентация • • • • • •

Подготовит. курсы. Спецкурсы. Факультативы. ЕГЭ-репетитор. Олимпиады. Корректирующие курсы. Спец. школы.

Методическая работа • Методические комиссии. • Разработка справочных и профессиографических материалов. • Курсы повышения квалификации. • Разработка рекламноинформационных материалов.

Система довузовской подготовки

Экскурсии, беседы. Профдиагностика. Дни открытых дверей. Выездные презентации вуза. Научные школы. Конкурсы.

Научно-исследовательская работа Исследование и анализ: • Социально-демографической ситуации в регионе. • Факторов, определяющих уровень образовательной и научно-практической подготовки абитуриентов.

Рис. 1. Направления работы факультета довузовской подготовки У факультета довузовской подготовки дела идут достаточно хорошо, но вследствие сложной демографической ситуации 90-х годов количество выпускников общеобразовательных, начальных и средних профессиональных учреждений в текущий период резко сократилось, что накладывает определенные трудности по набору абитуриентов в вузы, приводя к усилению конкуренции на рынке образовательных услуг. Кроме того, большой объем работ и документации, а также широкий спектр постоянных контактов с социальными партнерами привели к поиску путей повышения эффективности функционирования факультета довузовской подготовки путем оптимизации протекающих процессов. Процессный подход рассматривается как одно из возможных средств улучшения деятельности факультета довузовской подготовки СибГИУ. Появление международных стандартов ISO серии 9000 версии 2008 дало серьезный импульс к развитию методик процессного управления, который включает: описание и оптимизацию бизнеспроцессов, создание актуальных деятельных должностных инструкций и положений и т.д. [2, 3]. Для моделирования и оптимизации процессов решено использовать программный продукт BPwin, который позволяет визуализировать технологические и управленческие цепочки действий, событий и функций [4]. Выбор данного программного продукта обусловлен еще и тем, что он поддерживает стандарт описания процессов IDEF0, что позволит использовать результаты моделирования для создания информационной системы поддержки принятия решения по управлению факультетом довузовской подготовки. 124

Труды конференции Телематика’2010

Обозначим этапы, выполнение которых обеспечивает внедрение системы процессного управления [5]: • выявить процессы, необходимые для системы менеджмента качества, и их применения внутри организации; • определить последовательность этих процессов и их взаимосвязь; • определить критерии и методы, необходимые для обеспечения уверенности в том, что как сами эти процессы, так и управление ими результативны; • обеспечить уверенность в наличии ресурсов и информации, необходимых для поддержки хода реализации этих процессов и их мониторинга; • наблюдать, измерять и осуществлять анализ этих процессов, а также • реализовывать мероприятия, необходимые для достижения запланированных результатов и постоянного улучшения этих процессов. Проект выделения процессов и построения системы эффективного управления носит характер внедрения изменений, протяженных во времени. После завершения проекта изменения в организации не прекращаются, они будут производиться в рабочем порядке на основе анализа деятельности процессов и предназначено для дальнейшего повышения эффективности деятельности организации [6]. Проект внедрения процессного управления в организации является одним из самых сложных и длительных проектов. Руководству организации предстоит пересмотреть всю систему управления. Оставить без изменения то, что эффективно работает и выполняет все предъявляемые требования. Найти части системы управления, нуждающиеся в изменениях, разработать и внедрить эти изменения. Руководству предстоит наладить систему регулярного поступления информации для всех уровней управления и систему регулярного принятия решения по этой информации. В каждой организации существует несколько различных циклов планирования с разной периодичностью, соответственно циклы контроля выполнения планов также будут различаться и будут привязаны к циклам управления и планирования. Периодичность планирования и контроля зависит от уровня управления, на котором рассматривается данный объект управления. Даже у владельцев процессов может быть несколько циклов планирования и контроля: ежемесячное планирование, контроль и отчетность перед вышестоящим руководителем; еженедельное планирование и контроль и даже ежедневный контроль хода процесса с принятием управленческих решений по фактам отклонений показателей процессов от установленных значений. Руководителям и владельцам процессов придется учесть все эти циклы при построении системы поступления информации и регламентации управленческой деятельности [7]. Таким образом, в рамках системы процессного управления выделяя, документируя и анализируя процессы можно предложить изменения, обеспечивающие эффективность функционирования как организации в целом, так и отдельного структурного подразделения в привязке к общей системе управления вузом. Литература 1. 2. 3.

4. 5. 6. 7.

ISO 9000:2008 Системы менеджмента качества. Основные положения и словарь. ISO 9001:2008 Системы менеджмента качества. Требования. Ольве Н.Г., Рой Ж., Веттер М. Оценка эффективности деятельности компании: Практическое руководство по использованию сбалансированной системы показателей: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. Репин В.В., Маклаков С.В. ARIS Toolset / ВРwin: выбор за аналитиком // Компьютер пресс. 2002. № 1. Джордж С, Ваймерскирх А. Всеобщее управление качеством: стратегии и технологии, применяемые сегодня в самых успешных компаниях. (TQM). – СПб.: Виктория-плюс, 2002. Шадрин А. Некоторые аспекты практической реализации процессного подхода // Стандарты и качество. 2003. № 6. Репин В.В., Елиферов В.Г. Процессный подход к управлению: Моделирование бизнеспроцессов. – М.: РИА «Стандарты и качество», 2004.

ГРАФИЧЕСКИЕ ПРЕДСТАВЛЕНИЯ АТОМНЫХ СПЕКТРОВ И ИХ РЕАЛИЗАЦИЯ В ИНФОРМАЦИОННОЙ СИСТЕМЕ «ГРОТРИАН» Г.Д. Безматерных, Д.Н. Шиманский Новосибирский государственный университет E-mail: [email protected] Введение Проведение исследований в атомной спектроскопии подразумевает сбор и анализ данных об оптических свойствах атомов и ионов – характеристиках энергетических уровней и радиационных переходов, причем исследователям необходима как табличная [1–4], так и графическая форма представления таких данных в виде диаграмм Гротриана [5–8].

125

Существующие специализированные ИС не предоставляют нужной функциональности, такой, например, как динамическое построение диаграмм Гротриана, и исследователи вынуждены искать необходимую информацию для решения своих задач в книжных изданиях, или строить диаграммы Гротриана самостоятельно. Но для большинства сложных задач литературных источников может быть недостаточно, а построение диаграмм вручную может занять существенное время. В настоящее время существует несколько попыток решить данную проблему, но они не решают её полностью, например, NIST USA – одна из самых развитых на сегодняшний день ИС обладает функциональностью построения диаграмм Гротриана, но при этом не производит отбора радиационных переходов. Таким образом, актуальной является проблема создания ИС, умеющей строить диаграммы Гротриана автоматически, воспроизводя работу исследователя при подборе и размещении отображаемых переходов. Цели и задачи исследования Целью данной работы является исследование способов автоматической визуализации атомных спектров, проектирование и построение ИС, обеспечивающей динамическое построение диаграмм Гротриана с отбором отображаемых радиационных переходов. В процессе исследования ставятся следующие задачи: • Анализ существующих специализированных ИС по спектральным характеристикам атомов и ионов, выявление их возможностей и недостатков, анализ требований исследователей к ИС, формулирование общих требований к ИС по спектральным характеристикам атомов. • Анализ существующих практик построения диаграмм Гротриана, выработка общих требований к таким диаграммам и формализация требований к построению графического представления спектров атомных систем в виде машинно-ориентированных алгоритмов. • Проектирование и реализация расширенной концептуальной модели БД ИС, проектирование и построение интерфейсов ввода и вывода данных. Реализация сайта системы, публикация в Интернет, реализация и интегрирование в ИС средства автоматического построения диаграмм Гротриана в векторном формате. • Актуализация БД ИС «Электронная структура атомов» по атомным системам с LS-связью в объеме достаточном для апробации системы. Научная новизна Научная новизна данного исследования заключается в разработке алгоритмов автоматического построения диаграмм Гротриана и, в том числе, уникального алгоритма отбора радиационных переходов для отображения на диаграмме. На сегодняшний день, самой развитой и полной ИС по спектральным данным атомов и ионов является NIST USA. Но и в этой системе, так же как во всех остальных, отсутствуют средства построения диаграмм Гротриана с автоматическим отбором отображаемых радиационных переходов. Практическая ценность Результаты данной работа могут использоваться в исследованиях в таких областях науки, как атомная спектроскопия, астрофизика и физика плазмы, а также в учебном процессе. Также сделанная ИС впоследствии может стать национальной ИС по спектральным данным атомов, а разработанные подходы к построению системы и алгоритмы могут использоваться другими исследователями для собственных работ. Работа выполнена на базе ММЦ НГУ и ИАиЭ СО РАН в рамках гранта РФФИ № 0507-90220-в «Информационная система «Электронная структура атомов» с динамическим построением графических представлений спектральных данных». Основные характеристики анализируемых ИС При анализе ИС был составлен список оцениваемых параметров, а также выработана методика экспертной оценки каждого параметра. Сводные данные по всем исследованным системам приведены в таблицах 1–5. Таблица 1. Заполненность данными Название ресурса 1. ASD 2. HASD 3. DAS 4. CHIANTI 5. SPECTR-W3 6. ELASA 7. ALL 8. AMODS 126

2. По уровням энергии (номера элементов в периодической таблице) 1-36; 42; 57-71 1-99 6; 8; 10 данные отсутствуют 1-94 89-99 данные отсутствуют 8; 11-16; 19-29; 36; 42; 57-71

3. По радиационным переходам (номера элементов в периодической таблице) 1-99 1-99 6-33 данные сортированы по длинам волн 1-94 89-99 данные сортированы по длинам волн 6; 12; 13; 16; 21

Труды конференции Телематика’2010

9. ЭСА-1 10. ЭСА-2

4, 10, 12, 67, 70 1-21, 28-32, 34-37, 54-71, 74, 80, 87

4, 10, 12, 67, 70 1-21, 28, 37, 54-56, 74, 80, 87

Таблица 2. Возможности таблиц уровней энергии Название ресурса

1. ASD 2. HASD 3. DAS 4. CHIANTI 5. SPECTR-W3 6. ELASA 7. ALL 8. AMODS 9. ЭСА-1 10. ЭСА-2

Выбор единиц измерения 1 энергии . + -

Вывод дополнительной информации2

Библиографические ссылки

Выборка уровней по параметрам3

Сортировка по параметрам4

+ -

+ + + -

+ +/-

+ +

Таблица 3. Возможности таблиц радиационных переходов Название ресурса 1. ASD 2. HASD 3. DAS 4. CHIANTI 5. SPECTR-W3 6. ELASA 7. ALL 8. AMODS 9. ЭСА-1 10. ЭСА-2

Выбор единиц измерения 5 параметров + + -

Вывод дополнительной информации6 + -

Библиографи ческие ссылки + + -

Выборка переходов по параметрам7 ++ +/+ ++ -

Сортировка по параметрам8 + +

Таблица 4. Построение диаграмм Гротриана Название ресурса

Умеет строить 9 диаграмму

Функциональност ь10

Выделение информации11

1. ASD 2. HASD 3. DAS 4. CHIANTI 5. SPECTR-W3 6. ELASA 7. ALL 8. AMODS 9. ЭСА-1 10. ЭСА-2

+ + +

+ +/+/-

+ +/+/-

Вывод дополнительной информации12 + -

Отбор переходов +

1

Волновые единицы или электрон-вольты. Энергия терма, энергия расщепления уровня. 3 Например, вывести уровни с энергией не более 4 эВ. 4 Например, отсортировать уровни по убыванию энергии. 5 Выбор единиц измерения длины волны и энергии уровней. 6 Диапазон выводимых длин волн, относительная интенсивность. 7 Например, вывести переходы с диной волны не более 7000 ангстрем. 8 Например, отсортировать по убыванию интенсивности. 9 Обладает возможностью автоматического построения диаграмм Гротриана, без отбора переходов. 10 Обладает дополнительной функциональностью, например детализацией диаграммы по энергии. 11 Например, выделение переходов в определенном диапазоне длин волн. 12 Например, всплывающие подсказки, с точной информацией об энергетическом уровне или радиационном переходе. 2

127

Таблица 5. Дополнительные возможности систем Название ресурса

1. ASD 2. HASD 3. DAS 4. CHIANTI 5. SPECTR-W3 6. ELASA 7. ALL 8. AMODS 9. ЭСА-1 10. ЭСА-2

Вывод таблиц по частям + + -

Вывод таблиц в ASCII формате + -

Выбор выводимых в таблице столбцов + + + -

Таблица Менделеева

Библиография

Помощь

-/+ + -/+ +

+ + + -

+ + -

Из таблиц видно, что систем, достаточно развитых для широкого использования в исследованиях, очень мало. Систем, которые умеют строить диаграммы Гротриана, всего две. А системы, которая при построении диаграммы выполняла бы отбор радиационных переходов, просто не существует, если не считать результаты данного исследования (ЭСА-2). Общие требования к ИС «Электронная структура атомов» Основываясь на проведенном анализе, а также на требованиях исследователей было сформулировано, что для качественного построения ИС необходимо, чтобы она удовлетворяла следующим требованиям: • Открытый доступ к системе через Интернет. • Удаленный доступ для заполнения данных информационной системы специалистами. • Графическое представления данных – построение диаграмм Гротриана, содержащих информацию об энергетических уровнях атома и возможных переходах (спектре). Переходы должны отбираться с помощью специального алгоритма. • Табличный вывод точных данных с поддержкой сортировки, выборки и поиска по различным параметрам, таким как уровень энергии данного состояния, длина волны перехода, время жизни уровней, вероятность переходов. • Наличие библиографических ссылок. • Полнотекстовые научные статьи. • Комментарии к выводимым данным. • Наличие вспомогательной и справочной информации для облегчения работы с системой. Общие требования к виду диаграмм Гротриана Существует несколько видов связей, с помощью которых описываются электронные структуры атомных систем и все графические построения должны учитывать эти особенности электронного строения. Электронная структура большинства атомных систем описывается с помощью LS-связи [23, 24], поэтому для таких систем и были сформулированы эти требования. В дальнейшем, при расширении функциональности системы для работы с другими видами связей, требования к виду диаграмм Гротриана будут пересмотрены. Общие требования к виду диаграмм Гротриана можно разбить на требования к шапке диаграммы, требования к отображению уровней и требования к отображению переходов [25]. Требования к шапке диаграммы. Шапка диаграммы должна содержать информацию о конфигурации, терме и атомном остатке уровня энергии. 2 5 2 5 • Конфигурация уровня должна отображаться в стандартной нотации: 2s 2p nf или 2s 2p nf '. 2 о • Атомные остатки должны отображаться в стандартной нотации: P 1/2. 2 о • Строка термов должна отображаться в стандартной нотации: P 1/2. Шапку можно создавать вручную, вводя в XML-документ данные. Можно автоматизировать этот процесс путем анализа уровней, содержащихся в базе для данного элемента. При этом можно анализировать информацию о конфигурациях, термах и атомных остатках, основываясь только на реальных данных. А можно проанализировать все конфигурации уровней, а затем с помощью специального алгоритма получить все теоретически возможные термы и атомные остатки для данной конфигурации. • На диаграмме должна быть шкала энергий, она может быть как линейной, так и логарифмической, -1 а также с различными единицами измерения (эВ, см ). • На шкале энергий могут быть разрывы. Разрывы появляются в том случае, если в достаточно большой диапазон энергий не попадает энергетических уровней. Тогда отображение этого диапазона энергий становится бессмысленным. Определение места для разрывов может быть также автоматизировано путем поиска диапазона энергии, в котором нет уровней. При этом, таких диапазонов, как и разрывов, может быть более одного. 128

Труды конференции Телематика’2010

Требования к отображению уровней. На диаграмме должны отображаться все уровни данного атома, в том числе автоионизационные и ридберговские. Все уровни должны отображаться в соответствии с их значениями энергий. Уровни должны подписываться конфигурацией и подписи не должны дублироваться. Подписи не должны ухудшать читаемость диаграммы. Уровни могут быть протяженными. Введение протяженных уровней улучшает читаемость диаграммы. Протяженная линия может быть выше или ниже соответствующего ей уровня, если их несколько, и они находятся рядом. Подписи на диаграмме надо располагать в самую последнюю очередь, чтобы они не мешали отображению других, более важных элементов. Более того, можно оставить по одной подписи для каждого терма, если диаграмма слишком загружена. Требования к отображению переходов. Переходы отображаются в виде линий, между уровнями. Переходы должны быть обозначены длиной волны. При выборе отображаемых переходов предпочтение должно отдаваться резонансным, потом по возможности двухфотонным или трехфотонным переходам. По длине волны более предпочтительны переходы из видимого и ИК областей спектра, как наиболее доступные исследователям. По интенсивности – наиболее интенсивные. Подпись перехода может находиться в любом месте перехода – главное, чтобы она не пересекалась с другими подписями. Выбор правил построения диаграмм Гротриана для системы «Электронная структура атомов» Основываясь на сформулированных общих требованиях к виду диаграмм Гротриана, были выработаны правила начертания диаграмм для ИС «Электронная структура атомов». Первоначальный вид построенной диаграммы был назван каноническим. В дальнейшем пользователь может менять этот вид в соответствии со своими исследовательскими задачами и требованиями, пользуясь предоставленной интерактивностью.

Рис. 1. Диаграмма Гротриана Li I Алгоритмы построения диаграмм Гротриана Существует несколько подходов к реализации клиента, строящего диаграмму Гротриана. 1. «Тонкий клиент». В случае тонкого клиента построение диаграммы производится на сервере, а клиенту выдается XML-документ в формате SVG с готовой диаграммой. В случае каких-то изменений сделанных пользователем, клиент посылает серверу запрос, и сервер снова строит XML-документ с диаграммой Гротриана. Основной плюс данного пути в том, что пользователю не надо устанавливать и использовать Java VM на своем компьютере. 2. «Толстый клиент». В случае толстого клиента сервер посылает клиенту XML-документ с данными, необходимыми для построения диаграммы. Далее клиент преобразует этот документ в SVG и отдает браузеру. При этом пользователю необходимо иметь Java VM на своем PC. Все расчеты в этом случае ведутся на клиентской машине. 3. «Тонкий клиент + JavaScript». В этом подходе клиент получает XML-документ в формате SVG с готовой диаграммой, как и в случае с тонким клиентом. Отличие в том, что в случае каких-то изменений, сделанных пользователем, с SVG-документом работает JavaScript на стороне клиента, и взаимодействие с сервером больше не требуется. Также не требуется иметь Java VM на своем PC. Для 129

проектирования и реализации ИС «Электронная структура атомов» был избран именно этот подход за свою гибкость и быстродействие. Общая схема отрисовки ДГ на SVG 1. Пользователь нажимает на кнопку «Получить диаграмму» и клиент передает серверу запрос с номером элемента. Сервер формирует XML-документ с информацией о шапке диаграммы, уровнях и переходах. При этом переходы сортируются с помощью алгоритма сортировки переходов, реализованном с помощью языка Леммы. Результатом является XML-документ, содержащий все данные, необходимые для построения диаграммы Гротриана. 2. С подготовленным XML-документом работает ряд алгоритмов, преобразуя его в полноценную SVG диаграмму: • Алгоритм создания шапки диаграммы. • Алгоритм создания шкал энергий и разрывов. • Алгоритм отрисовки уровней энергии. • Алгоритм отбора переходов. • Алгоритм размещения подписей к переходам. • Алгоритм размещения подписей к уровням. • Алгоритм размещения аббревиатуры элемента. Результат: Диаграмма Гротриана приемлемого качества. 3. Далее диаграмма отображается с помощью SVGViewer. В случае необходимости пользователь может воспользоваться дополнительной функциональностью диаграммы, реализованной на JavaScript, например, детализировать диаграмму по энергии, или выделить переходы в определенном диапазоне длин волн. Заключение В результате проведенных исследований получены следующие результаты: • На основе анализа существующих специализированных ИС по спектральным данным атомов и ионов и анализа требований исследователей сформулированы основные требования к ИС по спектральным данным атомов. Показано, что автоматическое построение диаграмм Гротриана с отбором переходов является важной функцией, еще не реализованной ни в одной системе. • Проанализированы различные диаграммы Гротриана и выработаны общие требования к таким диаграммам, предложен набор алгоритмов для автоматического построения графического представления спектров атомных систем, на основе предложенных алгоритмов реализованы средства автоматического построения диаграмм Гротриана в векторном формате • Спроектирована и реализована концептуальная модель БД ИС, оптимизированная по скорости исполнения стандартных запросов к системе. Спроектированы и построены интерфейсы ввода и вывода данных, реализован сайт системы, система опубликована в Интернет (http://asd.nsu.ru) • БД ИС заполнена данными в объеме 19420 уровней и 18223 перехода по 53 элементам – в основном атомные системы с LS-связью. Система была представлена на нескольких конференциях и конкурсах и получила положительные отзывы экспертов. ИС строит диаграммы приемлемого качества для ряда элементов щелочной, щелочноземельной группы, группы инертных газов и некоторых других – всего 21. Таким образом, построенная, опубликованная в открытом доступе в Интернет ИС «Электронная структура атомов» может строить графические представления спектральных данных приемлемого качества. Так же система может эффективно использоваться в исследованиях в области атомной спектроскопии, астрофизики и физики плазмы, а также в учебном процессе. В будущем планируется дальнейшее увеличение базы данных, за счет внесения атомных систем с jj, jl- и со смешанной связью, разработка и создание модулей построения альбомов диаграмм, что позволит создавать оригинал-макеты для издательских систем. Работа выполнена при финансовой поддержке РФФИ (грант №08-07-00306а) и ФЦП «научные и научно-педагогические кадры инновационной России» (госконтракт НК 421-17) Литература 1. 2. 3. 4. 5. 6.

130

Moore Ch. Atomic Energy Levels. Washington: NSRDS – NBS 35, 1971. Vol. 1-3. Martin W. C., Zalubas R., Hagan L. Atomic Energy Levels the Rare-Earth Elements. NIST – NBS. – Washington, 1978. Стриганов А., Свентицкий Н. Таблицы спектральных линий нейтральных и ионизированных атомов. – М.: Атомиздат, 1966. Одинцова Н., Стриганов А. Таблицы спектральных линий нейтральных и ионизированных атомов. – М.: Энергоиздат, 1982. Moore Ch., Merill P. Partial Grotrian Diagrams of Astrophysical Interest. Washington: NSRDS – NBS 23, 1968. Baskin S., Stoner J. Atomic Energy Levels and Grotrian Diagrams. – Amsterdam: North Holland, 1975-1982. – Vols. 1-4.

Труды конференции Телематика’2010

7. 8. 9.

10.

11.

12.

13.

14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.

Физические величины: Справочник / Под ред. Е.З. Мейлихова, И.С. Григорьева. – М.: Энергоатомиздат, 1991. Яценко А. С. Диаграммы Гротриана нейтральных атомов. – Новосибирск: ВО «Наука», 1993. Пляхин Ю.А., Казаков В.Г., Пожидаева Н.П., Яценко А.С. Информационная система "Электронная структура атомов" с автоматическим построением диаграмм Гротриана. // Тезисы Х Всероссийской конференции с участием иностранных ученых "Распределенные информационно-вычислительные ресурсы" (Электронное издание http://www.ict.nsc.ru/ws/show_abstract.dhtml?ru+127+9192), Новосибирск, 2005. Пляхин Ю.А., Казаков В.Г., Пожидаева Н.П., Яценко А.С. Информационная система "Электронная структура атомов" с автоматическим построением диаграмм Гротриана группы щелочных элементов. // ХХIII Съезд по спектроскопии. Тезисы докладов, Москва, 2005. Пляхин Ю.А., Казаков В.Г., Пожидаева Н.П., Яценко А.С. Научно-образовательная информационная система «Электронная структура атомов». // Тезисы докладов XI Международной научно-методической конференции "Новые информационные технологии в университетском образовании", Кемерово, 2006. Пляхин Ю.А. Информационная система «Электронная структура атомов» // Тезисы докладов конференции-конкурса работ студентов, аспирантов и молодых ученых «Технологии Microsoft в теории и практике программирования», Новосибирск, 2006. Пляхин Ю.А. Информационная система «Электронная структура атомов» с автоматическим построением диаграмм Гротриана для щелочноземельных элементов. // Материалы XLIV международной научной студенческой конференции «Студент и научно-технический прогресс», Новосибирск, 2006. http://physics.nist.gov/PhysRefData/ASD/index.html http://physics.nist.gov/PhysRefData/Handbook/index.html http://dprose.nifs.ac.jp/DB/Auto/ http://wwwsolar.nrl.navy.mil/chianti_linelist.html http://spectr-w3.snz.ru/index.phtml http://www.lac.u-psud.fr/Database/Contents.html http://www.pa.uky.edu/~peter/atomic/ http://amods.kaeri.re.kr/ Тюменцев А.С. «Информационная система «Электронная структура атомов»» - Дипломная работа магистра НГУ, Новосибирск, НГУ, 2005. Фриш С.Э. Оптические спектры атомов. – М.: Физматгиз, 1989. Ельяшевич М.А. Атомная и молекулярная спектроскопия. – М.: Физматгиз, 1962. Казаков В.Г., Тюменцев А.С., Яценко А.С. Информационная система “Электронная структура атомов” с динамическим построением графического представления спектральных данных. // Автометрия,. Новосибирск, 2005. Том 41, №6, С. 115.

СОЗДАНИЕ СПЕЦИАЛИЗИРОВАННОГО ИНСТРУМЕНТАЛЬНОГО ПОРТАЛА ВИРТУАЛЬНЫХ МУЗЕЕВ И НАУЧНЫХ КОЛЛЕКЦИЙ Ю.Л. Попович, М.Е. Рябченко Мультимедиа центр Новосибирского государственного университета, г. Новосибирск E-mail: [email protected] Введение Основной задачей музея является сохранение культурных ценностей и предоставление доступа к культурному наследию. Задача предоставления доступа к культурному наследию решается разными способами, самый распространенный – это организация различных выставок. Но выставка – это мероприятие локальное, и, как правило, не постоянное. Эти два факта существенно ограничивают доступ к культурному наследию и, как следствие, уменьшают значимость конкретного музея в целом. Перенос экспозиций и выставок в виртуальное пространство – еще одно решение задачи просвещения. Виртуализация подразумевает организацию в сети Интернет общедоступного ресурса, зайдя на который пользователь получает возможность ознакомления с виртуальными копиями реальных музейных экспонатов. Создание подобных виртуальных музеев является достаточно эффективным решением задачи просвещения масс, так как виртуальный музей доступен из любой точки мира, где есть Интернет, и работает 24 часа в сутки. Однако, создание качественного виртуального музея – достаточно сложная задача, которая требует значительных затрат. Среди музеев, в обычном понимании, есть так называемые «малые» музеи. Такие музеи не имеют официального статуса музея, существуют за счет энтузиастов и, чаще всего, не имеют постоянных источников финансирования. Тем не менее «малые» музеи так же хранят культурные ценности и 131

стремятся предоставить доступ к своим экспонатам всем желающим. В малых музеях обычно остро стоит проблема представления доступа к культурному наследию. Чаще всего, это следствие физической невозможности (отсутствие помещений, территориальная удаленность) принять посетителя. Такого рода проблемы могут быть решены с помощью публикации виртуальной копии «малого» музея в Интернете. Однако существует проблема: создание виртуальных копий «малых» музеев. Проблема состоит в невозможности использования стандартных подходов к созданию виртуальных музеев и в отсутствии специализированных средств для виртуализации «малых» музеев. Таким образом, на сегодняшний день является актуальным создание системы, которая бы позволила пользователю без особых затрат и привлечения специалистов из области ИТ: • Создать виртуальный музей, настроенный на нужную ему предметную область. • Актуализовать виртуальный музей с помощью дружественных для пользователя (user-friendly) инструментов. • Опубликовать и поддерживать виртуальный музей в рабочем состоянии. Предлагаемое решение Предполагается создать сервис (специализированный инструментальный портал виртуальных музеев), предоставляющий пользователю услугу специализированного хостинга. Данный сервис должен позволить пользователю с помощью встроенных инструментов создать свой собственный виртуальный музей. Виртуальный музей будет создаваться на физически удаленном сервере. Так же пользователю будут предоставлены все инструменты для удаленной актуализации виртуального музея и возможность его публикации для общего доступа в сети Интернет. Анализ терминологии и структур данных, используемых в музейной деятельности Создание виртуального музея – это, в первую очередь, своеобразная проекция реальных структур и методов в виртуальную среду. Таким образом, для создания полноценного виртуального музея необходим анализ терминологии и приемов, используемых в реальных музеях, и представление таких структур в виртуальное пространство. Подобный подход упростит дальнейшее общение пользователя с виртуальным музеем, так как пользователю будет интуитивно понятна структура виртуального музея. Основной миссией музея является сохранение культурных ценностей и просвещение масс. Перед виртуальным же музеем в первую очередь ставится задача просвещения, задача хранения для виртуального музея является косвенной, так как музейными объектами являются цифровые копии, ценность которых не так велика. Путем анализа музейной деятельности и консультаций с музейными хранителями были выделены несколько основных приемов и структур, используемых в реальных музеях. Фонды музея – научно организованная совокупность принадлежащих музею музейных предметов и научно-вспомогательных материалов. Фонды музея являются основой для реализации ведущих направлений музейной деятельности, а также базой источников для профильных музею наук. Фонды могут хранить любые типы музейных объектов – от картин и портретов до окаменелых останков динозавров и каждый тип имеет свои собственные атрибуты. Однако фонды являются нутром музея и никогда не выставляются напоказ. В виртуальном музее фонды должны представлять некий систематический каталог музейных объектов, причем должна быть возможность помещать в фонды любые типы музейных объектов. С помощью фондов музейные работники смогут отбирать экспонаты и использовать их с целью наполнения экспозиций или в других приемах, необходимых для представления музейных объектов конечному посетителю. Однако, в виртуальном пространстве есть возможность позволить посетителю виртуального музея просматривать фонды, что обычно невозможно в случае реального музея. Музейная экспозиция. Термин «экспозиция» происходит от латинского «expositio» – выставлять и означает в широком смысле любую совокупность предметов, специально выставленных для обозрения. Наиболее раннее определение музейной экспозиции – часть музейного собрания, выставленная для обозрения. Современное музееведение под музейной экспозицией понимает целостную предметнопространственную систему, в которой музейные предметы и другие экспозиционные материалы объединены концептуальным (научным и художественным) замыслом. Музейная экспозиция – основная форма музейной коммуникации. Создание виртуального аналога музейной экспозиции в виртуальном музее необходимо для реализации просветительских функций виртуального музея. Музейная экскурсия – форма культурно-образовательной деятельности музея, основанная на коллективном осмотре музея под руководством специалиста по заранее намеченной теме и специальному маршруту. Особенностью музейной экскурсии является сочетание показа и рассказа при главенствующей роли зрительного восприятия, которое дополняется впечатлениями и моторного характера: осмотр с разных точек зрения, на различном расстоянии. Такой прием, как музейная экскурсия, достаточно сложен для реализации в виртуальном пространстве, так как теряются многие важные аспекты. Но, тем не менее, реализация данного приема в виде учебной лекции с аудиосопровождением вполне приемлемое решение. Анализ существующих программных решений и технологий, используемых при создании виртуальных музеев Путем анализа многочисленных виртуальных музеев, технологий и информационно-справочных систем, используемых в музеях, было установлено, что большинство виртуальных музеев, созданных и опубликованных в сети – это виртуальные представительства реальных музеев. Как правило, разработка 132

Труды конференции Телематика’2010

виртуальных музеев производится штучно, на заказ. На выходе получается хороший красивый и дорогой виртуальный музей (например, виртуальные музеи Третьяковской Галереи, Лувра, Музея имени Н.К. Рериха). К сожалению, такой способ не может быть применим для виртуализации малого музея ввиду отсутствия необходимых ресурсов. Так же множество информационно-справочных систем, используемых в реальных музеях, имеют возможность выставления в интернет экспозиций (например, ИСС «НИКА-Музей», КАМИС). Но такие ИСС также обеспечивают решения широкого круга музейных задач: учет и хранение, каталогизация, подготовка выставок и экспозиций и т.п., что делает такие системы очень дорогостоящими. Такой подход к виртуализации так же не приемлем для малых музеев. Рассмотрим интернет-технологии и подходы, которые могут быть использованы, малыми музеями для виртуализации. Рассмотрим два основных подхода к публикации в сети информационных ресурсов. • Собственный сервер – публикация ресурса в сети путем приобретения, настройки и последующей поддержки собственного сервера. • Хостинг – публикация ресурса в сети путем использования услуги хостинга, то есть размещение информации на удаленном сервере, постоянно находящемся в сети. Оба варианта имеют свои преимущества и недостатки, однако относительно малых музеев более предпочтительным является второй вариант, так как в этом случае не требуется дополнительных затрат на приобретение сервера и оплату услуг специалиста для последующей поддержки сервера. Теперь рассмотрим два основных метода создания виртуального музея, наиболее актуальных для малого музея. • Использование CMS-системы для создания и наполнения веб-сайта. • Использование HTML-редактора для создания собственно веб-сайта. Второй вариант подразумевает владение некоторыми навыками программирования, что не всегда имеет место среди членов коллектива малых музеев. В первом же случае предоставляется некая система управления с помощью, которой можно создать свой собственный веб-сайт. С точки зрения малого музея первый вариант является более предпочтительным. Проведем анализ доступных CMS-систем, подходящих для создания виртуального музея. Первым классом проанализированных систем станут так называемые интернет-галереи. Интернет-галерея представляет собой CMS-систему, позволяющую создать веб-сайт для отображения фотографий и объединения их в альбомы. В интернет-галереях, как правило, ограниченное и фиксированное количество атрибутов у фотографий, нет возможности создавать экспозиции и т.п. Интернет-галереи могут частично покрывать потребности виртуального музея, но не полностью, так как они для этого не предназначены. Следующий предмет анализа – это класс CM-систем, позволяющих с помощью различных веб-интерфейсов и интегрированных редакторов создавать собственные веб-сайты. Примерами, где используются такие системы, являются различные блоговые сервисы, такие как живой журнал, и сервисы для создания «домашних страниц», например «Яндекс.народ». С помощью подобных систем можно создать виртуальный музей только в самом простом виде. Реализовать же всю функциональность, необходимую виртуальному музею, не представляется возможным. На сегодняшний день не существует доступной малому музею системы, позволяющей создать вебресурс, обеспечивающей функциональность, необходимую малому виртуальному музею. Все вебресурсы, поддерживающие такую функциональность создаются под заказ, либо являются постпродуктом ИСС. Разработка доступного сервиса, позволяющего легко создать, актуализировать и опубликовать виртуальный музей является актуальной. Выявление основных требований к системе управления виртуальным музеем научнообразовательной направленности На основе анализа был сделан вывод, что на сегодняшний день не существует программного продукта, удовлетворяющего потребностям малых музеев по части создания виртуального музея. Предлагается разработать инструментальный портал, предоставляющий каждому музейному коллективу собственную систему управления виртуальным музеем, ориентированную на «малый» музей. Система управления виртуальным музеем должна удовлетворять следующим требованиям: предоставлять пользователю функциональность, позволяющую: • Добавлять и осуществлять каталогизацию, а также представление музейных объектов. • Добавлять и представлять справочные материалы. • Составлять из музейных объектов стенды, а из стендов экспозиции. • Создавать виртуальные лекции или экскурсии, имеющие ссылки на музейные объекты и справочные материалы. • Иметь возможность публикации всех созданных и добавленных материалов в сети Интернет. Модель данных виртуального музея должна быть построена таким образом, чтобы обеспечить потребности всех функциональных модулей. Каждый функциональный модуль должен являть собой некий аналог действительного музейного механизма используемого в реальных музеях. Анализ таких механизмов и подходов был проведен выше. Некоторые функциональные модули, как и реальные их аналоги, при использовании в разных предметных областях имеют разную структуру данных. Поэтому итоговая модель каждого виртуального музея должна создаваться индивидуально для каждого конкретного виртуального музея. Таким образом, выявлен ключевой подход к системе управления виртуальным музеем. Предполагается каждому коллективу малого музея, пожелавшему создать свой виртуальный музей, 133

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

Схема сборки виртуального музея Так же была запроектирована возможность изменения модели данных уже созданного виртуального музея. Была разработана утилита, позволяющая переносить пользовательские данные между музейными оболочками. На данный момент разработанная утилита переноса данных, работает в режиме «как есть». Это позволяет без привлечения специалиста расширить модель данных виртуального музея новыми типами музейных объектов, или сузить, удалив ненужный музейный тип (но при этом потеряв данные). Предлагается реализовать редактор многоразовым, чтобы была возможность загрузки созданного файла настроек и его редактирования. После редактирования создавать новую оболочку виртуального музея. Затем производить перенос пользовательских данных из старой версии виртуального музея в только что собранную оболочку. Старая версия оболочки при этом удаляется и подменяется новой. 134

Труды конференции Телематика’2010

Типовая оболочка виртуального музея Типовая оболочка виртуального музея спроектирована с учетом всех выдвинутых требований. Типовая концептуальная модель виртуального музея построена на основе объектно-ориентированного подхода. Все объекты, хранящиеся в такой БД, представляют собой элементы классов. Каждый класс имеет набор атрибутов и набор методов. Классы связаны между собой отношениями. Концептуальной моделью данных в такой БД является модель классов. Положительной особенностью при использовании такой БД является возможность запрограммировать функции управления данными прямо в методы классов. Концептуальная модель виртуального музея строится из классов и отношений между этими классами. Классы объединены в несколько функциональных блоков. Практический каждый функциональный блок представляет собой отображение реально существующей музейно-выставочной структуры в виртуальное пространство. Разработанные функциональных блоки полностью покрывают функциональность, необходимую «малому» музею. Заключение Описанный подход специализированного хостинга имеет практическую ценность, так как может быть применен при решении проблем публикации виртуальных музеев и научных коллекций в сети Интернет. Созданная в рамках указанного подхода система – «инструментальный портал виртуальных музеев» – может быть применена держателями малых музеев и научных коллекций для виртуализации своих музеев и коллекций. В том числе в процессе работы данной возможностью уже воспользовалось несколько музеев и научных коллекций, поддерживаемых университетом и СО РАН. Работа выполнена при финансовой поддержке РФФИ (грант № 08-07-00229-а), РГНФ (грант №08-0312127в) и ФЦП «Научные и научно-педагогические кадры» госконтракт НК-50-6. Литература 1. 2. 3. 4. 5. 6.

Российская музейная энциклопедия http://museum.ru/rme/. Сайт образовательного проекта «Letopisi.ru» http://letopisi.ru. Центр-музей имени Н.К. Рериха http://www.icr.su/. Виртуальный музей Лувра http://www.louvre.fr/. Cognitive Technologies ИСС НИКА-Музей http://www.cgntv.com/products/nika_museum1.htm. КАМИС. Комплексная автоматизированная музейная информационная система http://www.kamis.ru/. 7. Государственная Третьяковская галерея http://www.tretyakovgallery.ru/. 8. Виртуальный музей «Древнее искусство Сибири» http://mmedia.nsu.ru/museum/. 9. Виртуальный музей «История информатики» http://mmedia.nsu.ru/cshistory/. 10. З.В. Баяндина, А.М. Задорожный, В.Г. Казаков, Н.В. Каменский, И.А. Лебедев. Организация информации в учебных ресурсах, построенных на базах данных: решение на основе метамодели данных. Вестник НГУ. Серия: Информационные технологии / Новосиб. гос. ун-т. Новосибирск, 2004. Т. 1. Вып. 2. С. 73–90.

АВТОМАТИЗИРОВАННАЯ СИСТЕМА МОНИТОРИНГА ПРОДУКТИВНОСТИ РАБОТЫ АСПИРАНТОВ А.Г. Власова, О.Ю. Насадкина Петрозаводский государственный университет E-mail: [email protected] Регулярный контроль и оценка продуктивности работы аспирантов является частью внутривузовского мониторинга и представляет собой одну из центральных задач информационноаналитического обеспечения процесса подготовки научных кадров высшей квалификации. Информационно-аналитическая система «Аспирантура» (http://aspirant.karelia.ru), разработанная Петрозаводским государственным университетом (ПетрГУ), содержит модуль мониторинга качественного состава аспирантов. Сложность сбора и обработки необходимой информации сведена к минимуму за счет использования web-технологий при проведении мониторинга. Выделены шесть основных типов пользователей: аспирант; научный руководитель; сотрудник кафедры/факультета, ответственный за научную работу в соответствующем подразделении; администраторы системы (специалисты отдела аспирантуры, руководство вуза), внешний пользователь (например, поступающий). Реализована система персонифицированного доступа к информации: каждому типу пользователей поставлен в соответствие определенный уровень доступа к ресурсам и совокупность функциональных возможностей. Диалог, как между пользователями, так и между пользователем и системой осуществляется через web-интерфейс. При разработке механизмов мониторинга на первый план выходят задачи определения набора показателей, по которым отслеживается состояние образовательного процесса; создания инструментария контроля и оценки результатов. 135

Система значимых параметров-характеристик модели оценки научно-исследовательской работы молодых ученых довольно сильно варьируется от вуза к вузу. В настоящее время суммарно используется более шестидесяти различных индикаторов результативности. В работах, посвященных проблеме определения численных характеристик деятельности молодых ученых, также предлагается к рассмотрению и обосновывается значимость ряда показателей продуктивности. Таким образом, актуальной является задача отбора статистически значимых характеристик работы аспиранта. Рассмотрим обобщенный набор показателей. В нем встречаются следующие отношения: тождества, наличие непустого пересечения (в том числе случай полного включения), отсутствие непустого пересечения. Имеются индикаторы, которые представляют собой точную сумму других, более детализированных признаков. Например, xn – число актов о внедрении, xn1, xn2, xn3 – число актов о внедрении соответственно в производство, в учебный процесс, в общественные организации, следовательно, xn= xn1+xn2+xn3. К индикаторам, имеющим непустое пересечение, относятся в частности xm1 – число тезисов или публикаций статей в сборниках международных конференций, xm2 – число тезисов в материалах всероссийских и международных конференций. В пересечение попадают тезисы, опубликованные в материалах конференций международного уровня. Наличие показателей такого типа обуславливает необходимость введения в рассмотрение набора дополнительных переменных, не имеющих пересечения. На основании обобщенного и дополненного набора показателей можно выделить следующие основные сферы деятельности (vi, i=1..7), подлежащие оценке: выполнение обязательной образовательной программы, выполнение расширенной образовательной программы, работа над диссертацией, публикационная активность, участие в конференциях, участие в различных конкурсах, грантах, программах, педагогическая деятельность. Сформулируем задачу в терминах статистического исследования зависимостей. Деятельность аспиранта, выступающая элементарным объектом исследования (O), характеризуется рядом признаков (входных переменных) различного типа. Объединенный и дополненный список индикаторов X=(x1, x2, ..., xp) будем рассматривать как первоначальную систему входных переменных, предикторов. В результате преднамеренных изменений или изменений, происшедших с независимыми переменными случайно, появляется эффект, который передается на так называемые выходные переменные, переменные-отклики. В качестве переменной-отклика предлагается рассматривать факт защиты диссертации в срок (y). Таким образом, каждому элементарному объекту исследования (деятельности конкретного аспиранта) ставится в соответствие перечень анализируемых показателей, т.е. O ↔ (x1, x2, ..., xp; y). Теперь задачу статистического исследования зависимости между переменными в вышеопределенных терминах можно сформулировать так: как изменения предикторов (xi, i=1.. N) влияют на значения отклика (y). Выбор того или иного метода корреляционного анализа зависит от целей проведения исследования и шкалы измерений, которой принадлежат входные и выходные переменные математической модели. Основная часть объясняющих признаков (число публикаций, участие в конференциях и т.п.) относится к метрической шкале отношений. Однако, очевидно, что специфика объекта исследования предполагает наличие переменных, измеряемых скорее качественно, чем количественно. Например, индикаторы, связанные с оценкой работы над диссертацией, такие как «полное освоение экспериментальной методики и завершение эксперимента», «мнение научного руководителя о работе аспиранта» относятся к порядковой шкале. Ей же принадлежат и оценки, полученные при сдаче экзаменов кандидатского минимума. Переменная-отклик представляет собой номинальный дихотомический признак. Вывод о существования статистической зависимости между двумя признаками, заключение о силе или слабости этой зависимости должно быть сделано на основе анализа таблиц сопряженности. Получив набор таблиц сопряженности, последовательно применим к его элементам статистический критерий хи-квадрат. При проведении теста хи-квадрат проверяется взаимная независимость двух переменных таблицы и благодаря этому косвенно выясняется зависимость обоих переменных. В качестве коэффициента корреляции применяется коэффициент Спирмена. Кроме того, для редукции множества исходных признаков может быть использован метод, основанный на теоретико-множественных отношениях между признаками, определенных выше, и корреляционном анализе. Подсчитаем корреляции между xi (для всех i) и итоговой переменной. Анализ данного набора корреляций позволил в первом приближении определить необходимый уровень детализации ряда рассматриваемых индикаторов. В частности, когда корреляции между дочерними элементами некоторого интегрального признака xi и результирующей переменной y близки к нулю, в то время как корреляцию xi и y можно расценивать как «сильную», предлагается исключать избыточные индикаторы, тем самым снижая размерность пространства значимых факторов модели. Встречается и обратная ситуация, когда корреляции между дочерними элементами xi некоторого интегрального признака x и результирующей переменной y значительно превышают корреляции между x и y. Так получило математическое обоснование мнение многих экспертов о нецелесообразности включения в систему индикаторов показателя – суммарное число публикаций. На этапе определения класса допустимых решений необходимо описать класс функций F, в рамках которого будет производиться дальнейший поиск конкретного вида исследуемой зависимости. Одним из основных критериев выбора модели является природа (количественная, неколичественная) 136

Труды конференции Телематика’2010

объясняющих и результирующих показателей. Принадлежность предикторов к порядковой шкале и шкале отношений, дихотомического отклика – к номинальной шкале обуславливает целесообразность применения бинарной логистической регрессии. Функции данного класса рассчитывают вероятность наступления события (p=P{y=q}, 0<=q<=1) в зависимости от значений объясняющих переменных X. Соответствующая вероятность p рассчитывается по формуле:

p = f(X; θ) = 1/(1+e-( b1x1+b2x2+…+bnxn+a)), где X – вектор предикторов, θ={b1, b2, …, bn;a} – вектор параметров, расчет которых является задачей бинарной логистической регрессии. Таким образом, поиск искомой связи между объясняющими переменными и откликом будет осуществляться среди параметрического семейства функций f(X; θ). Этап вычисления оценок неизвестных параметров, входящих в исследуемое уравнение статистической связи полностью автоматизирован благодаря использованию соответствующего программного обеспечения. Определение значения вектора θ={b1, b2, …, bn;a} было произведено с помощью статистического пакета SPSS Statistics. Параметры b1, b2, …, bn – положительны. Далее, простая проверка показывает, что функция f(X; θ) является монотонно возрастающей относительно каждой переменной-предиктора. Это свидетельствует о том, что повышение значений входных переменных способствует росту величины результирующей переменной, хотя и с разной степенью силы. Увеличение определенного коэффициента соответствует повышению степени положительного влияния соответствующего признака, то есть наиболее значимые факторы имеют наибольшие значения коэффициентов bi. Приведем список пяти наиболее влиятельных индикаторов результативности: • Работа над диссертацией. • Публикация в журнале, включенном в список ВАК. • Выполнение расширенной образовательной программы. • Очное участие на конференции всероссийского (международного) уровня с докладом. • Наличие финансовой поддержки исследования на всероссийском уровне. Для оценки качества модели логистической регрессии существует эффективный инструмент ROCанализа. ROC-кривая (Receiver Operator Characteristic) – кривая, которая может быть эффективно использована для представления результатов класса задач классификации с двоичной выходной переменной. В таких задачах решается вопрос о принадлежности объекта к одному из двух классов. Один из данных классов называется классом с положительными исходами, второй – с отрицательными исходами. Предполагается, что у регрессии имеется некоторый параметр, варьируя значение которого, мы будем получать различные разбиения исследуемого множества на классы с положительными и отрицательными исходами. Этот параметр часто называют порогом, или точкой отсечения (cut-off value). ROC-кривая показывает зависимость количества верно классифицированных положительных примеров от количества неверно классифицированных отрицательных примеров. Первые называются истинно положительным, вторые – ложно отрицательным множеством. Далее введем некоторые обозначения. • TP (True Positives) – верно классифицированные положительные примеры (истинно положительные случаи). • TN (True Negatives) – верно классифицированные отрицательные примеры (истинно отрицательные случаи). • FN (False Negatives) – положительные примеры, классифицированные как отрицательные (ошибка I рода, ложно отрицательные случаи). Это так называемый «ложный пропуск» – когда факт успешной защиты в срок (y=1) имел место, но не был обнаружен моделью. • FP (False Positives) – отрицательные примеры, классифицированные как положительные (ошибка II рода, ложно положительные случаи). Это ложное обнаружение – когда при отсутствии события факта успешной защиты в срок, модель выносит ошибочное решение о его присутствии. При анализе чаще оперируют не абсолютными показателями, а относительными – долями, выраженными в процентах: • Чувствительность – доля истинно положительных примеров TPR = [TP/(TP+FN)]*100%; • Специфичность – доля истинно отрицательных примеров, которые были правильно идентифицированы моделью TPR =[TN/(TP+FN)]*100%. ROC-кривая получается следующим образом: Для каждого значения порога отсечения, которое меняется от 0 до 1 с шагом dx (например, 0,01) рассчитываются значения чувствительности Se и специфичности Sp. В качестве альтернативы порогом может являться каждое последующее значение примера в выборке. Строится график зависимости: по оси Y откладывается чувствительность Se, по оси X – 100%–Sp (сто процентов минус специфичность), то есть FPR – доля ложно положительных случаев. Идеальная модель, подразумевающая единичную площадь под ROC-кривой, обладает стопроцентной чувствительностью и специфичностью. Однако, на практике, в условиях невозможности добиться максимальных значений этих характеристик, возникает задача поиска максимально 137

эффективного соотношения между ними, что ведет к необходимости нахождения оптимального порога отсечения. Для определения наилучшего порога требуется задать критерий его определения, поскольку в разных задачах присутствует своя оптимальная стратегия. В качестве критериев выбора порога отсечения распространено использование: • требования максимальной суммарной чувствительности и специфичности модели Cut_off1 = max(Sek + Spk), k=1..100 • требования баланса между чувствительностью и специфичностью Cut_off2 = min(Sek – Spk) , k=1..100. В данном исследовании значения этих параметров равны соответственно 0,62 и 0,64. Cut_off

Se, %

Sp, %

Se+Sp

|Se-Sp|

…

…

…

…

…

0,61

91,6

87,3

178,9

4,3

0,62

91,4

88,2

179,6

3,2

0,63

91,1

88,4

179,5

2,7

0,64

88,1

88,6

176,7

0,5

0,65

88,1

88,9

177,0

0,8

…

…

…

…

…

Таблица 1. Фрагмент массива значений Se, Sp, Se+Sp, |Se-Sp|, соответствующих различным порогам отсечения В частности, согласно таблице 1, для Cut_off1=0,62 чувствительность составляет 91,4%, специфичность – 88,2%. В настоящем исследовании значение специфичности важно в первую очередь для обеспечения возможности принятия своевременных превентивных и коррекционных мер по минимизации случаев явных отставаний аспирантов от плана работы, отклонений от заданных требований. Использование модели с высоким уровнем чувствительности положительно сказывается на качестве поддержки процесса принятия решений при необходимости выделить успевающих, наиболее прогрессирующих аспирантов. Наличие сформированного набора статистически значимых объясняющих признаков и их вклада в продуктивность работы стало базой для реализации модуля учета деятельности аспиранта. В информационной системе «Аспирантура» данные о деятельности аспиранта структурированы и представлены в различных разделах. В частности, в разделе «Подготовка диссертации» отражается ход работ непосредственно над текстом диссертации. Представленные данные могут быть использованы для автоматической генерации списка литературы кандидатской диссертации. В разделе «Педагогическая деятельность» представлена информация об учебной и методической работе аспиранта. Раздел «Образовательная программа» отражает результаты кандидатских экзаменов (обязательная образовательная программа), посещение факультативных курсов (расширенная образовательная программа). Информация о печатных и электронных научных публикациях (статьях, тезисах докладов) аспирантов содержится в разделе «Публикации». Раздел «Конференции» предназначен для обеспечения поддержки планирования и учета участия аспиранта в симпозиумах, конференциях, семинарах, научных школах и т.п. При этом в базе данных фиксируется определенный статус мероприятия, например «отправлена регистрационная форма», «отправлены тезисы», «получено подтверждение регистрации» и другие. Информация, внесенная аспирантом в соответствующие разделы доступна научному руководителю для просмотра и частичного редактирования. В частности, имеется возможность добавлять ресурсы в список источников для подготовки диссертации, информацию о рекомендуемых конференциях, конкурсную документацию на получение грантов и т.п. Для обеспечения более высокого уровня взаимодействия предусмотрен механизм обратной связи посредством возможности добавления научным руководителем комментариев по каждому виду деятельности аспиранта. Кроме того, автоматизированное рабочее место научного руководителя позволяет частично управлять контентом портала «Аспирантура», в частности, путем размещения новостей, адресованных той или иной группе аспирантов (например, определенной кафедры, факультета). Указанные аспирантом виды деятельности могут быть одобрены научным руководителем или не рекомендованы к выполнению. Для этого предусмотрен механизм визирования. Первоначально, любая деятельность, внесенная аспирантом как планируемая, имеет статус «в процессе работы». Если 138

Труды конференции Телематика’2010

научный руководитель не возражает против её выполнения, он не изменяет статус. В противном случае он ставит визу «не рекомендуется к выполнению». Кроме того, результаты, достигнутые в части подготовки диссертации (экспериментальной деятельности, работы над текстом) и образовательной программы оцениваются научным руководителем качественно. Поскольку аспиранту каждый результат, достигнутый аспирантом, увеличивает его рейтинг, возникает проблема проверки корректности введенных данных. Таким образом, если выполнение конкретной деятельности завершено, то научный руководитель подтверждает данный факт путем визирования со статусом «выполнено». Результаты, соответствующие предикторам порядковой шкалы, научный руководитель оценивает качественно, фиксируя относительно рассматриваемого вида деятельности, насколько хорошо аспирант справился с рассматриваемыми задачами. Информационно-аналитическая система реализуется в архитектуре многоуровневой клиентсерверной модели. Ядро системы - интегрированная база данных, реализованная средствами СУБД Oracle9i, 10g. Для проектирования и создания приложения, обеспечивающего ведение информации специалистами отдела аспирантуры вуза, используется Oracle Developer Suite 6i, 10g (Designer, Oracle Forms, Oracle Reports, Oracle Graphics и Oracle Query Builder). Для создания web-приложений, реализующих доступ аспирантов, научных руководителей, руководителей подразделений к информационной системе применяется Oracle Application Server 10g, который позволяет интегрировать стандартные решения Oracle и разработанные на языке Java компоненты (портлеты), что способствует достижению большей гибкости реализованного решения. Реализована синхронизация данных с интегрированной информационно-аналитической системой (ИАИС) управления вузом, что позволяет избежать хранения избыточных данных.

WEB-СРЕДА РАЗРАБОТКИ PascalABC.NET Ю.В. Белякова, С.С. Михалкович Южный федеральный университет, факультет математики, механики и компьютерных наук, г. Ростов-на-Дону E-mail: [email protected] С развитием Интернета все более удобным становится использование для различных целей специализированных Интернет-сервисов (например, Google Docs). В этом отношении разработка программ – не исключение. В данной работе описан специализированный Интернет-сервис, предназначенный для разработки программ на языке Паскаль прямо через браузер – Web-среда программирования PascalABC.NET. Рассмотрены ее основные возможности, реализация, а также интегрированными средами. Приведены варианты преимущества перед обычными использования. Введение На сегодняшний день все более важными условиями успешной разработки программ становятся мобильность (возможность моментального запуска программ на любом компьютере без установки соответствующего программного обеспечения), кроссплатформенность, а также сетевой доступ к файлам. Возможным решением данных задач является создание специализированного Интернетсервиса – мобильного дополнения к обычной интегрированной среде, а именно Web-среды программирования с личным архивом программ. В данной работе рассматривается Web-среда программирования PascalABC.NET [1]. PascalABC.NET [2] – это язык, совместимый с Delphi Object Pascal и ориентированный на платформу .NET. Web-среда функционирует непосредственно через браузер и доступна по адресу http://pascalabc.net/WDE/. Сервис, предоставляемый Web-средой программирования, существенно отличается от большинства Web-приложений. Во-первых, здесь необходима постоянная синхронизация многочисленных операций, производимых на клиенте и на сервере, так как практически любая команда приложения требует соответствующих действий на сервере. Отдельную сложность представляет синхронизация файловых операций на сервере с состоянием Web-редактора, а также браузера файлов на клиенте. Во-вторых, необходимо корректно обрабатывать большое число возможных ошибок. К стандартным сетевым ошибкам и ошибкам обращения к базе данных добавляются ошибки сервера, связанные с операциями над файлами и каталогами. В-третьих, дополнительные трудности вызывает высокая степень взаимодействия приложения с компилятором языка (например, для обеспечения интерактивного ввода/вывода). И, наконец, необходимо обеспечивать многоплановую защиту доступа от несанкционированных операций. 1. Существующие web-среды На сегодняшний день Web-среды разработки распространены сравнительно мало. Большинство из них связаны с разработкой на языках JavaScript, HTML и CSS, которые исполняются непосредственно браузером. Другим типом подобных сервисов являются online-компиляторы. Здесь текст программы из окна браузера отправляется на сервер, где передается соответствующему компилятору, а уже результат выполнения программы возвращается клиенту. 139

Далее рассмотрим три лучших, на наш взгляд, Web-среды: • IDEOne [3]. Система позволяет компилировать программы на 40 языках, компиляторы которых расположены на сервере. Результаты компиляции программ возвращаются на отдельной странице. Основным недостатком данной среды является отсутствие интерактивности — нет возможности использовать систему ввода. • WebDevStudio [4]. Достаточно функциональная Web-среда разработки, позволяющая компилировать проекты на языках C, C++ и Java. После компиляции можно скачать полученный exe- или class-файл на локальный компьютер и исполнить его. Однако, выполнение проекта через браузер невозможно. • CodeRun Studio [5]. Наиболее функциональная система из рассмотренных. Позволяет разрабатывать и исполнять Web-приложения на языках C#, PHP и JavaScript. Возможность разработки консольных приложений, к сожалению, отсутствует. В целом, список возможностей существующих систем достаточно велик. Однако ни одна из рассмотренных нами Web-сред не поддерживает интерактивную систему ввода/вывода (ввод/вывод во время выполнения программы). Для нас же интерактивность при работе с консольными приложениями, позволяющая максимально приблизить процесс разработки в Web-среде к привычному нам в настольных IDE, является одной из первоочередных задач. 2. Основные возможности web-среды PascalABC.NET Web-среда разработки PascalABC.NET представляет собой Web-аналог интегрированной среды разработки программ на языке Паскаль. Список ее возможностей можно разделить на две основные группы: базовые функции среды программирования и ее возможности как Web-приложения. Рассмотрим основную функциональность Web-среды. • Как и в обычной среде, программу можно компилировать и выполнять. Процесс выполнения программы также можно досрочно остановить. • Для разработки используется достаточно мощный Web-редактор с подсветкой синтаксиса, который позволяет работать с несколькими файлами одновременно, как и в обычной среде. • Поддерживается интерактивный ввод-вывод. • При обнаружении ошибок компиляции или выполнения курсор редактора позиционируется в соответствующее место программы. • Поддерживается работа с модулями и библиотеками. • Пользователь имеет возможность не только компилировать и выполнять программы через браузер, но и скачивать соответствующие exe- или dll- файлы на локальный компьютер. • Доступна возможность публикации файлов в общий каталог (публикуемая программа должна компилироваться). Соответствующий файл получает специальное имя и становится доступен по адресу http://pascalabc.net/WDE/?file=name.pas. Кроме того, любой пользователь может открыть такой файл непосредственно в редакторе, используя соответствующую кнопку. Также доступен список всех опубликованных файлов. • Поддерживается регистрация пользователей. Использовать систему могут как зарегистрированные, так и незарегистрированные пользователи. Последние, однако, работают во «временном» каталоге, доступном лишь в течение одного сеанса, в котором могут создавать и сохранять файлы исходных текстов. • Зарегистрированные пользователи получают в свое распоряжение постоянный каталог на сервере. Кроме того, зарегистрированные пользователи имеют возможность переименовывать и удалять файлы и папки, а также создавать дополнительные папки и подпапки внутри своего каталога (имеется простая навигация по папкам). • Доступен легко изменяемый администратором набор примеров программ на языке PascalABC.NET. 3. Техническое описание Система является ASP.NET-приложением. Широко используется технология AJAX, позволяющая минимизировать число видимых перегрузок страницы, тем самым ускорив работу приложения, а также максимально приблизить процесс программирования к привычному в настольных интегрированных средах. Для реализации клиентского слоя обширно используется язык JavaScript. Рассмотрим реализацию основных подсистем Web-среды. Компиляция и выполнение программ производятся на сервере, где расположен соответствующий компилятор. Браузер пользователя синхронизируется с сервером посредством специальных запросов AJAX. Рассмотрим данную схему подробнее. При нажатии кнопки «компилировать» или «выполнить» происходит следующее: текст пользовательской программы извлекается средствами редактора и отправляется в асинхронном запросе на сервер. Для этого используется AJAX-технология методов страницы: JavaScript-код вызывает статический метод сервера в виде PageMethods.<имя метода>(<параметры метода>, ). Далее, на сервере запускается компилятор, происходит выполнение программы, и результаты возвращаются клиенту как параметры , которая и вызывается на клиенте по завершению метода сервера. В зависимости от результата (ошибка компиляции, ошибка выполнения, данные для вывода) совершаются нужные действия. Например, при возникновении ошибки выполнения в окне вывода появляется ее текст, а 140

Труды конференции Телематика’2010

курсор редактора позиционируется в соответствующую строку. Если ошибка произошла не в открытом файле, то нужный файл предварительно открывается. Ввод-вывод. Рассмотрим следующую программу:

var x: integer; begin read(x); writeln('x = ', x); end. Как и в общем случае, при запросе на выполнение текст программы из окна редактора отправляется на сервер, где передается компилятору. Когда выполнение откомпилированной программы доходит до оператора read, процесс приостанавливается, и клиенту возвращается сигнал о том, что ожидается ввод. На странице среды появляется соответствующее окно ввода. После того как пользователь завершит ввод данных, вновь вызывается AJAX-метод страницы, который получает на вход введенную строку. Далее, уже на сервере, она передается ожидающему процессу, выполнение возобновляется и продолжается до следующего оператора ввода, вывода, ошибки выполнения или успешного завершения программы. Наличие в программе оператора write означает, что в процессе выполнения программы клиент получит от сервера сигнал об имеющихся данных для вывода, которые и будут отображены в соответствующем окне приложения. Для синхронизации операций ввода/вывода используется метод опроса: каждые 300 мс на сервер отправляется запрос на наличие новых данных. Если такие данные есть, то они возвращаются на сторону клиента и тут же отображаются. Работа с файлами. Основной задачей клиентского слоя приложения является обеспечение корректной работы системы управления файлами, например: отслеживание несохраненных и открытых файлов, предотвращение выполнения некорректных команд, обеспечение соответствия реальной файловой структуре сервера. Кроме того, именно клиентская сторона предоставляет визуальную компоненту работы с файловой системой. Например, браузер файлов реализован самостоятельно, при этом существенно использованы объектно-ориентированные возможности языка JavaScript. Непосредственно физические изменения в пользовательском каталоге сервера выполняются с использованием все тех же методов страницы AJAX. Клиент отправляет серверу необходимую информацию (например, при сохранении это – полное имя файла и его содержимое), на сервере запрошенная операция выполняется, а результат возвращается клиенту. Защита. Значительную роль в работе приложения играет защита пользовательских данных: в качестве механизма хранения паролей выбрано хеширование, а также используются средства ASP.NET для защиты от SQL-инъекций. С другой стороны, необходимо также обеспечить защиту сервера от умышленных (или случайных) потенциально опасных действий пользователя: например, попытки программным образом испортить файлы сервера. Данная возможность исключена – процессы выполнения пользовательских программ ограничены в доступе своим каталогом. Таким образом, файлы сервера не только нельзя испортить, но и даже невозможно программно получить информацию о существующих файлах и каталогах. Браузер файлов И, наконец, все процессы, запускаемые в среде, контролируются: в случае зависания процесса на сервере, через некоторое время он прерывается. 4. Некоторые технические проблемы В процессе разработки мы столкнулись с некоторыми техническими ограничениями ASP.NET. Например, удаление или переименование папки в каталоге приложения приводит к немедленному завершению сеанса. Указанная проблема оказалась весьма распространенной, однако, в качестве единственного решения предлагалась перезагрузка страницы, что неприемлемо ввиду низкой скорости. Было реализовано решение искусственно возобновлять сеанс, используя еще один AJAX-механизм ASP.NET – компонент UpdatePanel. Как только сессия работы приложения завершается, на этой панели программно генерируется событие, вызывающее отправку на сервер запроса. В результате выполнения данного запроса начинается новая сессия, при этом никаких визуальных изменений на странице не происходит. Еще одна проблема – невозможность использования стандартных компонентов ASP.NET для авторизации пользователей. Причина заключается в том, что данные компоненты используют перегрузку 141

страницы, которая, как было сказано выше, неприемлема. Дополнительной сложностью авторизации является необходимость синхронизированных изменений на клиенте и сервере. В итоге решением стало использование набора HTML-элементов, размещенных на AJAX-компоненте UpdatePanel. Работа с базой данных пользователей производится через специальный класс ASP.NET – Membership. Несмотря на то, что все операции авторизации (установка статуса пользователя или работа с Cookies) приходится совершать вручную, использование данного класса, инкапсулирующего работу с базой, в значительной степени повышает безопасность приложения. Для синхронизации клиента и сервера используются серверные события для обратной связи (объект Sys.WebForms.PageRequestManager). Заключение Таким образом, заявленная задача создания Web-среды программирования PascalABC.NET выполнена в полном объеме. Web-среда удовлетворяет базовым возможностям IDE, таким как: компиляция, выполнение, интерактивный ввод/вывод, позиционирование на ошибках, хотя и уступает по функциональности современным интегрированным средам. Однако она обладает рядом других важных преимуществ: • запуск программы на любом компьютере без предварительной установки соответствующего программного обеспечения; • хранение программ во внешнем хранилище с возможностью моментального запуска; • кроссплатформенность; • скорость выполнения; • всегда актуальная версия системы; • возможность создания специализированного архива программ. Указанные свойства, прежде всего, позволяют использовать Web-среду PascalABC.NET в качестве мобильного дополнения к основной среде [5], а в некоторых случаях она может выступать и в качестве единственного инструмента разработки. В настоящее время Web-среда программирования PascalABC.NET используется в учебном процессе при обучении основам программирования студентов специальности «Информационные технологии» мехмата ЮФУ. Кроме этого, Web-среда используется как специализированный файловый архив программ с возможностью публикации ссылок на запускаемые файлы на различных сайтах и форумах (аналогично Google Docs). Web-среда может использоваться: • как компонент при реализации дистанционного обучения программированию; • для организации автоматической проверки задач на олимпиадах по программированию; • в качестве тонкого клиента для реализации облачных вычислений. Литература 1.

2.

3. 4. 5. 6.

Ю.В. Белякова, И.В. Бондарев, С.С. Михалкович. Первое сообщение о Web-среде разработки PascalABC.NET. / Научно-методическая конференция «Современные информационные технологии в образовании: Южный Федеральный округ». Ростов-на-Дону, 2010. – С. 58–59. Н.Н. Водолазов, С.С. Михалкович, А.В. Ткачук. Опыт разработки учебного языка программирования для платформы .NET / Научно-методическая конференция «Современные информационные технологии в образовании: Южный Федеральный округ». Ростов-на-Дону, 2007. – С. 71–72. Электронный ресурс http://ideone.com/. Электронный ресурс http://gayuba5.datsi.fi.upm.es/~iortiz/webdevstudio/. Электронный ресурс http://www.coderun.com/ide/. Электронный ресурс http://pascalabc.net/.

WEB-СЕРВИС АВТОМАТИЗАЦИИ ВЫЧИСЛЕНИЯ МАТЕМАТИЧЕСКИХ МОДЕЛЕЙ А.В. Камынин Самарский государственный аэрокосмический университет им. академика С.П. Королёва, г. Самара E-mail: [email protected] Введение За годы существования Интернет состав web-приложений, выполняемые ими функции, принципы и архитектура их построения претерпели весьма значительные изменения – от простейших средств хранения HTML-страниц до современных решений, ориентированных на поддержку работы развитых корпоративными информационных систем. На сегодняшний день многие мировые лидеры в производстве программного обеспечения стремятся занять эту нишу, выпуская версии всем известных 142

Труды конференции Телематика’2010

приложений, доступных в виде web-приложений (web-сервисов). Яркими примерами этого могут служить такие web-приложения, как Google Docs от компании Google, SalesForce CRM от компании SalesForce, Microsoft Office Live от компании Microsoft. Несмотря на то, что web-приложения для браузера имеет ограничения, связанные с безопасностью и производительностью, их разработка более сложна и запутанна по сравнению с разработкой стандартных приложений, усилия обычно оправдываются, потому что: • не требуется установка приложения; обновление и распространение приложения – быстрый и автоматизированный процесс; • обновление версий автоматическое; • пользователи могут использовать приложение на любом компьютере, имеющем соединение с Интернет в независимости от установленной операционной системы; • при работе web-приложения компьютер пользователя гораздо меньше подвержен вирусному заражению, чем при запуске exe-файлов. Стоит отметить, что ниша сложных математических вычислений, требующих больших вычислительных мощностей от компьютера остаётся слабо тронутой в среде Интернет. Из-за отсутствия онлайн-аналогов пользователи больше отдают предпочтение настольному математическому программному обеспечению. Для такого ПО свойственно: • высокие требования к аппаратной части ПК; • индивидуальная работа. Над одним файлом в один момент времени может работать только один пользователь; • несовместимость файлов разных версий ПО. Однако применение Интернет в этой среде могло бы устранить эти недостатки и сделать возможным недоступную ранее совместную работу пользователей над одним массивом данных, поддерживая общение между ними в реальном времени. Важно отметить, что пользователи могут находиться на больших расстояниях друг от друга и поддерживать связь исключительно посредством Интернет. Цель и особенности Целью разработки web-сервиса является повышение эффективности индивидуальной и коллективной работы над математическими моделями в научной деятельности и учебном процессе за счёт применения web-технологий. Web-сервис (далее также «система») представляет собой сайт, доступный в сети Интернет. Web-сервис является адаптированной Интернет-версией CAD-системы, разработанной для удалённого использования посредством сети Интернет, и ориентирован на непрофессиональных или полупрофессиональных пользователей, не использующих широкие возможности дорогостоящих CADсистем, таких как MathCAD, Maple и других, а использующих данный сервис для решения локальных задач либо для обучения. Под локальными задачами подразумеваются: решение уравнений либо систем уравнений, построение графиков, вычисление сложных выражений. В отличие от упомянутых выше аналогов, одной из основных задач web-сервиса является предоставление пользователю возможности максимально быстро и без лишних затрат приступить к его использованию. Это достигается посредством следующих особенностей web-сервиса: • Использование модели SaaS (Software as a service – «Программное обеспечение как услуга», или Software on Demand «Программное обеспечение по требованию»). Это модель предоставления программного обеспечения, которая подразумевает разработку и управление web-сервисом самостоятельно, независимо от пользователей, предоставляя им доступ к сервису через Интернет. Основное преимущество модели SaaS для потребителя (пользователя web-сервиса) состоит в отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и программного обеспечения, работающего на нём. В данном случае это означает, что все рабочие данные и настройки пользователей хранятся на удалённых серверах, на которых также происходит их обработка. • Web-сервис является кроссплатформенным. Это означает, что его работа не зависит от операционной системы пользователя. Для взаимодействия с web-сервисом требуется только наличие браузера и подключения к сети Интернет. В web-сервисе приняты следующие понятия: • Рабочий лист (worksheet) – набор формул, графиков, результатов вычислений и комментариев к ним, объединенных общим смыслом. Рабочий лист хранится на сервере. Аналогом рабочего листа является файл. • Документ (document) – текстовая информация с описанием чего-либо, хранящаяся на сервере. Работа с системой состоит из нескольких этапов. Для начала работы пользователю необходимо пройти регистрацию, чтобы создать себе учётную запись, которую он впоследствии будет использовать для хранения рабочих данных. После подтверждения регистрации по e-mail, пользователю становятся доступны функции web-сервиса, а именно: создание и редактирование рабочих листов, создание и редактирование документов, публикация рабочих листов и документов для доступа к ним других пользователей, причём доступно может быть не только их чтение, но и изменение. Возможность публикации информации в системе для доступа к ней других лиц является очень важной особенностью системы. Это позволяет коллективно разрабатывать и обсуждать математические модели в рамках web-сервиса, не прибегая к использованию сторонних средств (таких как средства моментального обмена сообщениями, электронная почта и т.п.). После публикации данных их автором, 143

те пользователи, которые имеют к ней доступ, могут одновременно, работая параллельно за разными ПК, вносить в неё правки. Таким образом, достигается коллективная работа над поставленными задачами. В условиях постоянного совершенствования возможностей компьютерной техники, а особенно в условиях распространения глобальной сети Интернет, создание и внедрение компьютерных обучающих систем приобретает все большее значение. Автоматизация процесса обучения требует использования современных методик представления и обработки информации, использования последних достижений в области информационных и телекоммуникационных технологий, построения в рамках обучающей системы адекватной модели не только обучаемого, но и обучающего. Использование web-сервиса в сфере обучения может значительно упростить процесс коммуникации преподавателя со студентами и процесс контроля знаний посредством возложения большинства обязанностей на web-сервис. Рассмотрим пример работы с web-сервисом в сфере обучения. Здесь можно выделить два типа пользователей: преподаватель и студент. Преподаватель формулирует задание и помещает его в webсервис в виде документа, к которому открывает доступ на чтение для своих студентов, имеющих учётную запись в web-сервисе. Данные действия могут проводиться удалённо через Интернет. При получении студентом документа с заданием в системе, он может приступить к его выполнению в удобное для себя время. Как уже упоминалось, доступ к системе осуществляется удалённо и все данные хранятся на удалённых серверах, а это означает, что отпадает необходимость переносить рабочие файлы, и процесс решения одной и той же задачи может легко осуществляться как из учебного заведения, так и с домашнего компьютера. Кроме того, существует возможность вернуться к предыдущей версии рабочих данных, если сделанные изменения окажутся неверными, так как система хранит промежуточные версии рабочих листов и документов. После завершения работы над заданием, студент открывает доступ преподавателю на результирующий рабочий лист, и преподаватель может приступить к проверке. Так как у рабочего листа существуют ревизии (версии), то преподаватель может посмотреть ход работы студента и сделать вывод о степени знаний студента. Разграничивая учётные записи студента и преподавателя в системе можно установить ограничения таким образом, чтобы студенты не могли обмениваться данными, касающимися одного варианта задания, исключив возможность списывания. После проверки, общаясь внутри системы, преподаватель уведомляет студента о результатах. Доступность web-сервиса в сети Интернет предоставляет широкие возможности для публикации научных достижений и результатов исследования. Сервис, по сути, является виртуальным сообществом людей, интересующихся математическим моделированием, а значит, публикация материала на смежную тему в нём может достичь высокого уровня отклика из-за присутствия на сайте целевой аудитории. Организация сайта в форме виртуального сообщества преследует следующие цели: • объединение пользователей в группы по интересам; • каталогизация пользователями информации по различным характеристикам с использованием тегирования. Это позволяет пользователю самому определить удобные и понятные ему категории [1]; • простой обмен информацией между пользователями; • совместная работа; • возможность высказывания мнения пользователями, рецензирования. Предоставление доступа к системе как к сервису подразумевает возможность одновременного использования системы большим числом пользователей. При условии возложения на сервер обязанностей по выполнению вычислений, web-сервис будет являться требовательным к ресурсам сервера. Оптимальная работа в такой ситуации будет обеспечиваться использованием облачных вычислений (cloud computing). Это технология обработки данных, в которой компьютерные ресурсы и мощности предоставляются по требованию в необходимом объеме [2]. Достигается это за счёт виртуализации. В итоге, для поддержки приложения в рабочем состоянии существует ряд рабочих серверов, непосредственно выполняющих запросы пользователей и ряд балансирующих серверов, осуществляющих равномерное распределение этих запросов между всеми рабочими серверами. При этом увеличение процессорной мощности, объёма оперативной памяти и дискового пространства происходит незаметно для web-приложения при необходимости. Техническая реализация Разработка web-сервиса включает в себя разработку клиентской (видимой непосредственно для пользователя) и серверной (отвечающей за обработку и хранение данных) частей. Клиентская часть состоит из xhml-страниц с использованием Javascript и MathML для отображения формул. MathML (Mathematical Markup Language, язык математической разметки) – это язык разметки, основанный на XML, используемый для представления математических символов и формул в среде Интернет [3]. В качестве основы для серверной части используется язык программирования Python. Это высокоуровневый язык программирования общего назначения с акцентом на производительность разработчика и читаемость кода. Для выполнения математических вычислений и преобразований используется библиотека для Python с открытым исходным кодом SymPy. Заключение В рамках данной работы был произведён анализ потенциальных конкурентов, выявлены их сильные и слабые стороны. В результате этого анализа был сделан упор на следующие ключевые моменты при разработке данного web-сервиса: 144

Труды конференции Телематика’2010

• использование современных web-технологий; • коллективная работа; • организация сайта в виде виртуального сообщества; • предоставление пользователям вычислительных мощностей сервера. Web-сервис является доступным широкому кругу пользователей через Интернет. Целью его разработки является повышение эффективности работы над математическими моделями за счёт применения web-технологий. Литература 1. 2. 3.

А.В. Иващенко, А.Ю. Орлов, С.И. Вольман, И.А. Минаков. Виртуальные сообщества в сети Интернет. Организация и Управление // Самара: СНЦ РАН, 2008. – 99 с., ил. Облачные вычисления, http://ru.wikipedia.org/wiki/Облачные_вычисления. MathML, http://ru.wikipedia.org/wiki/MathML.

КОМПЬЮТЕРНАЯ ПОДДЕРЖКА МОНИТОРИНГА ИНДИВИДУАЛЬНЫХ ДОСТИЖЕНИЙ СТУДЕНТА НА УРОВНЕ ДИСЦИПЛИНЫ С.В. Ильичева Санкт-Петербургский государственный университет информационных технологий, механики и оптики E-mail: [email protected] Мониторинг качества образования активно развивается сегодня под влиянием концептуальных установок модернизации системы российского образования – ориентацией на обеспечение ее качества, доступности и эффективности. Квалиметрия качества образования в качестве измерительной базы все чаще избирает антропологические характеристики человека образующегося. В свою очередь, управление образованием имеет конечной целью саморазвитие всех участников педагогического процесса. Анализ теории и практики высшего профессионального образования показывает, что основным результатом процесса образования являются индивидуальные достижения обучающихся. Наиболее часто речь идет об образовательных достижениях, которые определяются как измеряемые результаты образовательной деятельности учащихся, отражающие уровень знаний и умений студентов, сформированность универсальных (общенаучные, инструментальные, социально-личностные и общекультурные) и профессиональных компетенций выпускников. Внимание современного социогуманитарного знания к проблемам личности, его центрация на конкретном человеке приводят к поиску нетривиальных средств актуализации сущностных сил человека в образовании. Одним из таких средств может стать рефлексивный мониторинг. Мониторинг имеет место везде, где фактическое сравнивается с намеченным, и главная его задача сводится к уменьшению разницы между ними. Основными проблемами мониторинга как научного метода изучения состояния наблюдаемых объектов являются: выбор параметров и критерии их отбора; способы осуществления непрерывного слежения и его периодичность; способ использования полученных данных, их анализ для предупреждения нежелательных отклонений, принятия решений по ликвидации затруднений в учебном процессе и другие. Под рефлексивным мониторингом индивидуальных достижений студента на уровне дисциплины подразумевается процедура отслеживания результатов обучения дисциплины на основе рефлексии и самооценки через организацию системы контроля, сбора, обработки информации, представляющей собой совокупность показателей для анализа, прогноза и моделирования учебного процесса, направленного на достижение поставленных целей. Рефлексивный мониторинг, при условии его разработанности, может стать процедурой, позволяющей оптимизировать развитие человека в образовании. Важнейшей функцией мониторинга в педагогическом процессе является систематическое обеспечение обратной связи. В соответствии с этим контроль учебной деятельности учащихся становится неотъемлемым элементом мониторинга. С точки зрения кибернетики, контроль призван обеспечить как внешнюю обратную связь (контроль преподавателя), так и внутреннюю (самоконтроль). Очевидно, что на ступени высшего образования возрастает роль самоконтроля, поскольку он более способствует развитию самосознания и познавательной активности, помогает студенту стать субъектом учебной деятельности. Практический опыт показывает, что, обучаясь по одной и той же программе, не все студенты усваивают материал одинаково. Более того, современная парадигма образования предполагает, что студент имеет право выбрать для себя желаемый уровень усвоения курса. Таким образом, студент получает полную систему ориентиров для осознанного выбора индивидуальной траектории усвоения курса. Необходимо также заранее спроектировать все этапы промежуточной и итоговой диагностики с тем, чтобы студент самостоятельно смог определить тот минимум знаний, который необходим лично ему для получения той или иной итоговой оценки. 145

Поскольку контроль должен быть всесторонним, то, планируя проведение контрольных мероприятий, следует охватить не только содержание курса, но и различные виды учебной деятельности. Очевидно, что разным видам деятельности студентов должны отвечать разные формы контроля. Рефлексивный мониторинг индивидуальных достижений студента на уровне дисциплины проводится в три этапа: подготовительный, практический, аналитический, что позволяет осуществлять регулярное отслеживание уровней усвоения теоретического и практического материала с целью прогнозирования успешности деятельности каждого учащегося и всего обучения в целом. Одним из важнейших элементов структуры модели мониторинга учебного процесса на уровне дисциплины является конкретизация целей обучения через уровни усвоения. Основой последовательной ориентации обучения на цели является оперативная обратная связь, которая пронизывает весь учебный процесс. В соответствии с этим в технологическом подходе к обучению выделяются [2]: • постановка целей и их максимальное уточнение; • формулировка учебных целей с ориентацией на достижение результатов; • подготовка учебных материалов и организация всего хода обучения в соответствии с учебными целями; • оценка текущих результатов, коррекция обучения, направленная на достижение поставленных целей; • заключительная оценка результатов. Способ постановки целей, который предлагает педагогическая технология, отличается повышенной инструментальностью. Он состоит в том, что цели обучения формулируются через результаты обучения, выраженные в действиях учащихся, причем таких, которые учитель или какой-нибудь другой эксперт может надежно опознать [1]. Для реализации этой идеи в теории образовательного мониторинга рекомендуется построение четкой системы целей, внутри которой выделены их категории и последовательные уровни. Для достижения целей профессионального образования наиболее эффективной является следующая иерархия уровней усвоения: знание, понимание, применение, анализ, синтез, оценка. Такой подход к целеполаганию позволяет добиться понимания и принятия учащимися целей и конечного результата обучения, организовать гибкий учебный процесс, выделив уровни обязательного усвоения содержания предмета всеми студентами и с учетом индивидуальных потребностей студентов. Учебный процесс считается оптимальным, если позволяет достичь максимально возможной успешности обучения с учетом условий его протекания. Моделирование оптимального учебного процесса осуществляется по следующим структурным компонентам: • выделение модулей в содержании дисциплины и разработка на этой основе модульной программы, в которой на изучение каждого модуля необходимо выделить определенное количество часов. Распределение часов может быть адекватным либо неадекватным поставленным целям, поэтому нормирование по времени является важным элементом мониторинга; • нормирование учебной деятельности по уровню усвоения учебного материала. Эти показатели классифицируют глубину проникновения и качество владения студентами учебным материалом; • разработка заданий контроля, позволяющих отслеживать уровень усвоения изучаемого материала. Контрольно-измерительные материалы (КИМы) контроля должны соответствовать форме проведения итогового контроля, т.к. их задачами являются проверка успешности обучения и формирование готовности к итоговому контролю. Нормирование КИМов осуществляется по временному фактору и в баллах; • организация педагогической и учебной деятельностей, которые в режиме мониторинга имеют специфические особенности. Выполнение «деятельности в режиме мониторинга» понимается как «деятельность в точно установленном распорядке действий». Педагогическая и учебная деятельности в режиме мониторинга имеют циклический характер, выполняются на нормативной основе с регулярным отслеживанием выполненных заданий и видов деятельности в баллах; наличием жестких условий допуска студентов к следующему этапу учебной деятельности. Педагогическая деятельность в режиме мониторинга не заканчивается проведением итогового контроля, она имеет дополнительный этап – прогнозирование успешности обучения в последующих циклах, обработка информации для моделирования оптимального учебного процесса в следующей учебной группе. На практическом этапе мониторинга осуществляется реализация смоделированного учебного процесса. Для успешности обучения важное значение имеет исходное состояние учебного процесса, т.е. насколько студенты готовы к изучению дисциплины, есть ли необходимость в актуализации знаний, необходимых для изучения дисциплины, насколько уровень обученности студентов соответствует требованиям, предъявляемым в учебном процессе и т.п. Для выявления исходного состояния используется самооценка индивидуальных достижений, позволяющая оптимизировать учебный процесс с учетом выявленного исходного состояния. Для активации механизма реагирования на полученную информацию и её использование для прогноза возможного развития учебного процесса, его коррекции, реализации оптимизированной модели обучения, повторения цикла движения информационного потока необходим анализ полученных результатов. В модель мониторинга учебного процесса на уровне дисциплины включены средства мониторинга для обработки полученной информации: 146

Труды конференции Телематика’2010

• минимальная норма по каждому учебному модулю принимается за «0», что позволяет анализировать результат успешности обучения на разных модулях; • предметные траектории показывают изменение знаний и навыков, их применение на каждом модуле дисциплины, строятся на основе таблиц успешности; • отклонения от нормы, где нормой является минимальный рейтинг, показывают динамику успешности или затруднений в учебном процессе. Прогнозирование осуществляется по двум направлениям: готовности студентов к итоговому контролю, профессиональной деятельности и по совершенствованию учебного процесса. На основе анализа результатов мониторинга разрабатываются рекомендации для студентов (продолжение обучения на более высоком уровне, готовность к сдаче экзамена, зачета, и т.д.) и для преподавателя, которые направлены на коррекцию конкретизации целей по предмету и исходной организации учебного процесса. Т.о. переход к 1 этапу мониторинга учебного процесса на уровне дисциплины означает начало нового цикла мониторинга, на котором идет дальнейшее уточнение норм, заданий, их сложности, времени и т.д. Многократное использование мониторинга учебного процесса на уровне дисциплины позволяет совершенствовать организацию учебного процесса, развивает педагогическую деятельность и способствует объективности оценки успешности обучения. Хелен Баррет выделяет ряд значимых факторов, которые должны способствовать развитию качества системы оценивания обучения: развитие когнитивных теорий и понимания предмета оценивания, развитие технологий измерений результатов, расширенные способы интеризации комплексных результатов обучения [6]. Сейчас весьма актуальной становится тема разработки инструмента эффективного мониторинга индивидуальных достижений студента. Такой технологией может стать портфолио. По сути, портфолио является лишь частью, конкретным видом так называемого «аутентичного оценивания». Аутентичное оценивание – это вид оценивания, применяющийся, прежде всего, в практикоориентированном образовании, и предусматривающий оценивание сформированности умений и навыков учащихся в условиях помещения их в ситуацию, максимально приближенную к реальной жизни – повседневной или профессиональной. В обучении на основе компетентностного подхода аутентичное оценивание направлено на выявление уровней сформированности компетентностей [4]. Е-портфолио позволяет: • поддерживать индивидуальные учебные цели и индивидуальные траектории обучения; • фиксировать изменения и развитие студента за определенный период времени; • демонстрировать результаты студентов не только преподавателю, а всему образовательному и профессиональному сообществу; • обеспечивать непрерывность процесса обучения от года к году («на протяжении всей жизни»). К настоящему времени в зарубежной педагогической практике разработан целый ряд моделей портфолио [7]. Как показал проведенный анализ, в их основе лежат общие принципы, характерные для аутентичного оценивания. Рассмотрим кратко основные их них. • Изменение целеполагания обучения и оценивания, которые становятся ориентированными на достижение результата. Так, целью учебного процесса становится «обучить учащихся умению учиться, исследовать сложные проблемы, решение которых предполагает сотрудничество, личную ответственность и толерантное отношение к ситуации неопределенности. • В соответствии с целевыми установками вторым необходимым условием для введения портфолио в учебный процесс становится создание особой учебной среды, которая позволяет учащимся конструировать собственное знание, развивать способности независимого мышления и действия, формировать особенности («привычки») мыследеятельностной и поведенческой сфер, которые позволят им стать компетентными и ответственными гражданами. • Проектная деятельность, как обязательная составляющая портфолио, предполагает компоненты исследования и планирования, от обучаемых требуются умения организовывать свое время, свои мысли; глубокое проникновение в процессы познания, критики и рефлексии относительно целого спектра тем и собственной деятельности; принятие и участие в установлении стандартов и требований к проекту; нахождение своего места в проекте. Процедура разработки е-портфолио студента осуществляется по следующему алгоритму: На первом этапе происходит сбор артефактов, которые формируются студентом самостоятельно и могут включать в себя текст, аудио, видео, анимацию, изображения и т.д. Подобный сбор документации имеет смысл, когда отобраны определенные пункты, сосредоточенные на специфических образовательных опытах или целях. Все отобранные материалы, включенные в собрание должны ясно отразить критерии и стандарты, идентифицированные для оценивания. На втором этапе портфолио демонстрирует процесс обучения. Оценивание данной части портфолио осуществляется по критериям и фиксируется в образовательном рейтинге студента, который служит основанием для готовности к итоговому контролю. Дополнительно, портфолио процесса неизбежно позволяет студентам рефлексировать процесс обучения, включая использование блогов, фиксирующих эти результаты. На третьем этапе портфолио лучше всего использовать для суммирования мастерства студентов, полученного по определенным пунктам учебного плана. Он должен включать лучшие работы студентов, отобранные как самими студентами, так и преподавателями. Только законченная работа должна быть включена. Показательный портфолио должен также включить письменный анализ и реакцию студентов 147

на законченный процесс, определяющий включенные работы. Достижения студента могут быть перенесены в базу данных вуза для дальнейшей оценки качества образования. При этом следует отметить, что цель создания портфолио студента может сводиться к доказательству прогресса в обучении по результатам, приложенным усилиям, по материализованным продуктам учебно-познавательной деятельности и т.д. Таким образом, акцент смещается с того, что студент не знает и не умеет, на то, что он знает и умеет по данной теме, данной дисциплины, в интеграции качественной оценки. И, наконец, акцент переносится с оценки обучения на самооценку [3]. Зарубежной педагогической практикой установлено, что для оценивания портфолио необходимо использовать восемь критериев для оценки любого типа портфолио. К ним относят: • необычная презентация идеи; • выполнение работы свыше возраста или ступени обучения; • комплексная или усложненная презентация идеи; • глубинное понимание проблемы или идеи; • хорошее обеспечение ресурсами и вдумчивое использование материалов; • наличие элементов исследования идеи; • хорошая коммуникативная организация материала для презентации; • наличие высокой степени интереса и настойчивости. Обязательным условием для формирования новой культуры оценивания для студента должно стать [5]: • осознание студентом критериев отбора артефактов для оценивания; • понимание критериев оценки личных результатов; • участие самих студентов в разработке индивидуальной траектории обучения; • свобода в отражении личностных качеств обучаемого. Портфолио действительно становится аутентичным инструментом оценивания, если включает в себя способы фиксации компетентностей и умений студентов в модельных кейс-ситуациях профессиональной деятельности. Технология электронного портфолио может использоваться в образовании для различных целей: оценивания, развития, презентации и обучения. Целью внедрения технологии е-портфолио является совершенствование подготовки студентов, за счет вовлечения в профессиональное самоопределение и развитие рефлексивных навыков самооценки собственных достижений и индивидуального прогресса в процессе обучения в университете на основе метода е-портфолио. Е-портфолио способствует развитию мышления и формированию критического отношения к учебной деятельности, расширяет возможности обучения и исследования, позволяет наглядно демонстрировать развитие по отношению к прежним результатам, включает студентов в понимание процесса внешней оценки и развивает их заинтересованность во внутренней самооценке, позволяет анализировать, актуализировать индивидуальные затруднения и найти пути их преодоления, мотивирует на рефлексию профессиональной деятельности и планирование карьеры. Преподаватели, администрация факультета и потенциальные работодатели получат обширный материал, который можно использовать как в системе оценивания, так и в системе рекрутинга. Артефакты, представленные в е-портфолио студентов можно использовать для наблюдения за индивидуальным прогрессом самих студентов и адекватности разворачиваемых учебных программ. Епортфолио студентов дадут бесценную обратную связь между заказчиками образовательных услуг и преподавателями. Позволят оценить учебную программу. Интерпретация материалов, представленных в портфолио, позволит администрации и преподавательской команде откорректировать программы подготовки студентов, понять какие проблемы существуют на уровне индивидуумов и на системном уровне реализации образовательных программ. Литература 1.

2.

3. 4.

5.

6.

148

Боровкова Т.И., Морев И.А. Мониторинг развития системы образования. Часть 1. Теоретические аспекты: Учебное пособие. – Владивосток: Изд-во Дальневост. ун-та, 2004. – 150 с. Голуб Г.Б., Чуракова О.В. Технология портфолио в системе педагогической диагностики: Методические рекомендации для учителя по работе с портфолио проектной деятельности учащихся. – Самара: Изд-во «Профи», 2004. – 62 с. Морев И.А. Образовательные информационные технологии. Часть 2. Педагогические измерения: Учебное пособие. – Владивосток: Изд-во Дальневост. ун-та, 2004. – 174 с. Новикова Т.Г., Пинская М.А., Прутченков А.С., Федотова Е.Е. Использование портфолио учащегося в предпрофильной подготовке и профильном обучении. Методическое пособие. – М.: 2008. – 114 с. Смолянинова О.Г. Е-портфолио в оценивании образовательных достижений и профессиональном развитии магистров // Информатика и образование. – 2009. – № 12. – С. 121–123. Barrett, H. (2007) Researching Electronic Portfolios and Learner Engagement: The REFLECT Initiative. Electronic Portfolio issue, Journal of Adolescent and Adult Literacy (International Reading Association). 50:8, pp. 436-449.

Труды конференции Телематика’2010

7.

Beetham, H. (2005) E-Portfolios in Post-16 Learning in the UK: Developments, Issues and Opportunities // A report prepared for the JISC e-Learning and Pedagogy strand of the JISC eLearning Programme. Режим доступа: http://www.jisc.ac.uk/media/documents/themes/elearning/eportfolioped.pdf.

АВТОМАТИЗИРОВАННАЯ СИСТЕМА РАЗРАБОТКИ САЙТОВ КАК RICH INTERNET APPLICATIONS НА БАЗЕ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ А.Ю. Савельев, И.М. Радченко, В.Е. Подольский, В.Е. Красильников Тамбовский государственный технический университет E-mail: [email protected] Общие сведения Системы управления сайтами, получившие широкое распространение в последнее время, облегчают разработку сложных Интернет-систем, однако ни одна из них не завоевала рынок, поскольку каждая система предназначена для определенной сферы применения и обладает рядом недостатков. Недостатки платформ приложений серверной стороны, такие как низкая функциональность, отсутствие визуальных средств управления, трудности с масштабированием привели к тому, что практически каждая компания создает свой инструментарий для получения более эффективной среды разработки. Помимо этого существует большое количество свободно распространяемых разработок и опубликованных исследований. Все подобные системы спроектированы для облегчения управления и изменения сайта (или сайтов, в зависимости от архитектуры системы), оперативного внесения изменений в содержание и дизайн. Можно выделить два основных направления развития таких систем: простое построение сайта для непрофессиональных пользователей, и предоставление платформы для построения сложных Интернет-систем. Благодаря разработке и развитию технологии RIA (Rich Internet application, «насыщенное Интернетприложение»), стало возможным появление многих систем, позволяющих любому пользователю без труда создать свою страницу или сайт, не используя ПО авторской разработки (Microsoft FrontPage, Adobe Dreamweaver и т.п.). Проблема всех существующих на данный момент CMS-систем состоит в ограниченности конструктивных возможностей и возможностей дизайна. Эти недостатки должна решить, активно развивающаяся в последнее время, так называемая сервис-ориентированная архитектура. Она представляет интернет-приложение как модули со стандартным интерфейсом. В последующем эти модули могут либо повторно использоваться в этом же приложении, либо вообще в другой системе. За счёт этого, пользователь, создающий сайт, не должен вручную программировать свой "сервис", а может выбрать уже имеющийся из набора сервисов и добавить его себе на сайт (рис. 1).

Рис. 1. Схема многократного использования сервисов Способность двух или более информационных систем или их компонентов к взаимодействию с целью употребления полученной таким образом информации называют интероперабельностью. Это определение объединяет в себе два понятия. Техническая интероперабельность означает совместимость систем на техническом уровне, включая протоколы передачи данных и форматы их представления. Семантическая интероперабельность – свойство информационных систем, обеспечивающее взаимную употребимость полученной информации на основе общего понимания системами ее значения. Если техническая интероперабельность в значительной степени обеспечивается уже существующими технологиями, то с семантическим уровнем взаимодействия дела обстоят сложнее. Семантическая интероперабельность пока находится исключительно в сфере ведения специалистов: они должны договориться между собой и реализовать эту договоренность. Только с появлением Webсервисов был найден стандарт, позволяющий объединить все корпоративные вычислительные платформы и инструментальные средства. Можно выделить следующие преимущества предлагаемого технологического решения: • для создания сайта пользователю не требуется иметь навыки программирования, не требуется знание языка HTML; 149

• имеется очень простая и мощная технология объединения пользователей в группы по интересам; • сервисы могут дорабатываться и изменяться независимо от пользователя сайта, причем этот процесс не требует внесения каких-либо изменений на сайте пользователя; • так как реестр сервисов разрабатывается на основе международного стандарта FDDI, появляется возможность подключения сервисов других провайдеров; • огромная экономия времени на создание сайта пользователя. Целью создания данной САПР является создание системы, которая совместит в себе все преимущества стандартных интернет-приложений с принципами сервис-ориентированной архитектуры и позволит пользователям, не имеющим навыков программирования, создавать свои полноценные Интернет-сайты. Описание системы Рассмотрим принцип работы САПР. Вначале пользователю предлагается выбрать шаблон уже готового сайта, который в последующем может быть отредактирован под нужды пользователя. Если пользователь не нашёл подходящего шаблона, то ему предоставляется возможность создать свой вебсайт с нуля, т.е. без использования каких-либо шаблонов. После этого пользователю нужно ввести основные параметры сайта: название, ключевые слова, размеры и т.д. Затем пользователю предлагается выбрать количество страниц, из которых состоит сайт. Для каждой страницы нужно ввести её индивидуальные параметры, такие как заголовок, фоновый цвет или картинка и т.д. После этого пользователю открывается так называемый дизайнер страницы, в котором он может расположить стандартные компоненты из палитры, а также добавить свой компонент или использовать чужой (рис. 2). Все стандартные компоненты в системе разделены на 4 больших группы: элементы управления, элементы компоновки, готовые компоненты и утилиты. Все компоненты имеют 7 стандартных свойства и неограниченное количество других свойств. Стандартные свойства – это координата расположения X, координата расположения компонента Y, длина компонента и его ширина, вращение компонента по осям X, Y и Z.

Рис. 2. Дизайнер страницы К компонентам группы "элементы управления" относят элемент "кнопка", "гиперссылка", "строка текста", "многострочный текст", "изображение" и "видео". У всех компонентов есть индивидуальные свойства, такие как, например, прозрачность, всплывающий текст-подсказка и т.д. К компонентам группы "элементы компоновки" относят элементы "панель" и "контейнер". Отличительной особенностью этих компонентов является то, что они могут быть родителями других компонентов, т.е. другие элементы могут находиться внутри элементов компоновки, при этом, если это возможно, наследовать их свойства. К компонентам группы "готовые элементы" относятся такие элементы, как, например "моя анкета", "фотогалерея" и т.д. Их отличительной особенностью является то, что они, как правило, состоят из нескольких более простых компонентов и поэтому предоставляют большие возможности пользователям, не знакомым с программированием. 150

Труды конференции Телематика’2010

В группе "утилиты" находятся компоненты "файловый менеджер", который предназначен для загрузки пользователем на сервер файлов, которые в дальнейшем могут быть размещены ссылкой на пользовательском веб-сайте, и "пользовательский компонент", который предоставляет возможность выбора пользовательского компонента из списка. Защита информации в системе Для обеспечения защиты персональных данных в системе используется шифрование данных представления сайта. При регистрации пользователя, ему предлагается ввести пароль для входа в систему, далее этот пароль хешируется с помощью алгоритма md5, а в базу данных записывается только результат хеширования. В дальнейшем при вводе пользователем пароля, он также хешируется и полученное значение сравнивается со значением в базе данных. Таким образом, даже если злоумышленник получит доступ к базе данных пользователей системы, он не сможет воспользоваться персональными данными пользователей. Если пользователь узнает адреса серверных сценариев системы, то может появиться возможность управления многими функциями системы от имени авторизованного клиента, в том числе злоумышленник сможет получить доступ к персональным данным пользователя, к исходным кодам вебсайтов и пользовательских компонентов. Для предотвращения этого, клиентская и серверная часть системы общаются по собственному защищённому протоколу. При каждом обращении к серверу, клиент отправляет ему 256-битный ключ, который известен только клиентской и серверной стороне и изменяется в течение времени. На серверной стороне проверяется правильность этого ключа и в случае, если ключ ошибочный, данный запрос игнорируется. Не зная алгоритма формирования этого ключа, злоумышленник не сможет обратиться к серверу и получить функции управления системой. Таким образом, создаётся защита от несанкционированного доступа ко всем подсистемам САПР. Внутреннее устройство САПР Язык sdxml (Site Description eXtended Markup Language – "Расширенный язык разметки для описания сайтов") – используется в САПР для описания общих свойств сайта, свойств отдельных страниц сайта, а также для описания свойств пользовательских и стандартных компонентов. Общие свойства сайта обычно хранятся в файлах index.xml (заголовок, ключевые слова и т.д.) и navigator.xml (описание свойств стандартного навигатора по страницам сайта). Файл index.xml содержит два раздела: раздел описания свойств сайта (properties) и раздел перечисления путей к файлам описания свойств страниц (pages). В разделе properties содержатся следующие свойства сайта: • name – имя сайта. Может состоять только из цифр и букв латинского алфавита. Используется при формировании пути к готовой странице (выбирается один раз и в последствии не меняется). • caption – заголовок сайта. Отображается в заголовке браузера на всех страницах сайта. • keywords – ключевые слова сайта. Аналог meta тегов в html. Используется для индексирования сайта поисковыми роботами. • bgcolor – фоновый цвет сайта. • numpages – количество страниц на сайте (от 1 до 20). • navigator – использование навигатора. Если установлен в true то на каждой странице будет отображаться стандартный навигатор по страницам сайта. Остальные свойства навигатора описываются в файле navigator.xml. В разделе pages перечислены пути и имена файлов, в которых описаны свойства отдельных страниц. Свойства отдельных страниц хранятся в файлах типа pageX.xml, где X – номер страницы. Эти файлы состоит из двух частей: подраздел описания свойств страницы (properties) и подраздел перечисления компонентов (components). В свою очередь подраздел components делится на подразделы описания свойств компонента и перечисление компонентов-потомков Язык sdxml также используется для описания свойств стандартных и пользовательских компонентов. Эти свойства хранятся в файлах описания компонентов (например RsPanel.xml) и представляют собой массив данных. Каждая ячейка массива описывает одно определённое свойство и может содержать следующие поля: • name – имя свойства компонента для пользователя; • iname – внутреннее имя свойства компонента, предназначено для обращения к данному свойству внутри программы. Может состоять только из цифр или букв латинского алфавита; • type – тип свойства компонента. (например string, number, bool и т.д.) • dvalue – необязательное поле. Обозначает значение свойства по умолчанию. • min – минимальное значение свойства; • max – максимальное значение свойства; • format – формат представления данных; • items – перечисление элементов списков. Типы данных в системе В языке sdxml принято использовать несколько типов данных. Все они используются для описания свойств компонентов. Представлены следующие типы: 151

• • • •

number – числовой тип данных. Может быть как целым, так и дробным; string – строковой тип данных, использует символы из кодировки utf8-bin; bool – булевый тип данных; list – список. Для этого типа данных обязательно использование поля items в массиве свойств. При добавлении свойства данного типа, на панели свойств компонента появится окно выбора из списка (ComboBox). • color – цвет RGB. При добавлении свойства данного типа, на панели свойств компонента появится окно выбора цвета из палитры (ColorPicker). • date – дата. Для этого типа данных возможно использование поля format в массиве свойств. Если оно не указано, то дата представляется в формате ГГГГ-ММ-ДД. При добавлении свойства данного типа, на панели свойств компонента появится окно выбора даты из календаря (DatePicker). • onclick – вызов вспомогательных функций. При использовании этого типа данных, на панели свойств компонента появится кнопка, при нажатии на которую будут вызваны функции, заранее выбранные разработчиком компонента (например, менеджер файлов, менеджер баз данных и т.д.). • file – файл. При использовании этого типа данных, на панели свойств компонента появится кнопка, при нажатии на которую будет вызвано окно загрузки файла. При выборе пользователем нужного файла, он будет автоматически загружен на сервер и у пользователя появится ссылка на него. • hidden – вспомогательный тип данных. Служит для сохранения информации о компоненте, которая меняется автоматически с помощью функций описанных в onclick. В статье рассмотрена система автоматизированного проектирования и разработки сайтов как RIA на базе SOA: структура системы, основные принципы функционирования, характеристики. Результатом проектирования является система, с помощью которой пользователь, даже не имеющий навыков программирования на языке HTML, Flash или Java, может самостоятельно спроектировать структуру и дизайн Flash-сайта, либо выбрать уже имеющийся дизайн из списка шаблонов. С развитием этой системы, её назначение может расшириться до информационной системы предприятия, на котором она установлена. Литература 1. 2. 3. 4. 5. 6.

152

A Revolution and Agility: Business Integration Through Service-Oriented Architecture – ORACLE, 2008. John Fronckowiak. SOA Best Practices and Design Patterns – ORACLE, 2008. Ben Margolis SOA for the Business Developer: Concepts, BPEL, and SCA – Mc Press, 2007. http://www.oracle.com/us/technologies/soa/index.htm. http://www.microsoft.com/soa/. https://www.ibm.com/developerworks/ru/webservices/.

Труды конференции Телематика’2010

Секция 3. Суперкомпьютинг

РАЗРАБОТКА РАСПРЕДЕЛЕННОЙ СИСТЕМЫ ДИНАМИЧЕСКОГО ПРОГРАММИРОВАНИЯ НЕЛИНЕЙНЫХ ПРОЦЕССОВ С ПРИМЕНЕНИЕМ МНОГОШАГОВОЙ ОПТИМИЗАЦИИ О.Н. Медведева, К.О. Боченина, А.А. Павлов, Т.В. Таравкова Владимирский государственный университет E-mail: [email protected]; [email protected] В современных условиях, характеризующихся частыми изменениями, актуально применение инновационных методов управления. В частности, становится возможным прогнозировать результаты принимаемых решений. Для этого требуется построить компьютерную модель, которая будет имитировать процессы движения ресурсных потоков. С помощью такой модели можно получать значения переменных, характеризующих систему, на заданном числе шагов моделирования. В случае, когда некоторые параметры модели меняются от стадии к стадии, встает проблема выбора эффективных управленческих решений. В данной работе описан разработанный нами подход многошаговой оптимизации параметров сложных динамических систем с дискретным временем. В общем случае динамическая система представляет собой любой объект или процесс, для которого однозначно определено понятие состояния как совокупности некоторых величин в заданный момент времени и задан закон, который описывает изменение (эволюцию) начального состояния с течением времени (закон эволюции). Реальным физическим системам, которые моделируются математическим понятием «динамическая система», присуще важное свойство детерминированности: зная состояние системы в начальный момент времени и закон эволюции, мы сможем однозначно определить дальнейшее поведение системы. Отметим, что понятие сложности системы включает в себя два аспекта – структурную (компоненты системы связаны между собой трудным для непосредственного восприятия образом) и поведенческую (наличие у системы сменяющих друг друга во времени состояний) сложность. В качестве методики поиска долгосрочного оптимального управления системой предлагается использование схемы Беллмана. При увеличении размерности векторов состояний и управляющих параметров задача перебора всех возможных значений состояний и вычисление для этих значений целевой функции превращается в весьма ресурсоемкую задачу, поэтому в методе динамического программирования, выгодно использовать для поиска условно оптимальных решений эвристические алгоритмы и методы параллельного программирования для ускорения расчетов. При постановке задачи динамического программирования формулируется некоторый критерий, подлежащий удовлетворению, рассматриваемый процесс разбивается на стадии во времени, на каждой стадии принимается решение, при котором достигается поставленная цель. В рассматриваемой задаче стадия – это один шаг моделирования. характеризуется совокупностью Состояние системы на стадии процесса под номером

ν

переменных

1

2

k

yν = { yν , yν ,..., yν } , где k

– число переменных состояния.

Кроме переменных состояния выбирается также группа управляющих параметров (контролируемых факторов)

uν = {uν1 , yν2 ,..., uνl } ,

где

l

– число управляющих параметров. Вектор их значений

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

Опишем принцип распараллеливания: Пусть

mi , i = 1, n

– количество возможных значений

i -го

параметра, характеризующего n

состояние

S k . Тогда количество возможных состояний составит D = ∏ mi . Пусть p

– количество

i =1

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

⎡D⎤ c = ⎢ ⎥ + 1. ⎣ p⎦

Очевидно, что узел с номером

p

будет обрабатывать меньшее

число состояний.

l ∈ 1, p можно mh = max mi . Значения

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

mh

i =1, n

на два и более порядка больше

то распараллеливание нужно производить по соответствующему параметру. Если незначительно больше

p,

mh < p

p, или

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

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

f :X →X

X динамической системы x(t + 1) = f ( x(t )) .

фазового пространства

простых итерационных формул вида

на себя, а именно в виде набора

При таком способе представления на каждой итерации точка, изображающая вектор фазовых координат, будет совершать прыжки в фазовом пространстве ( x координат,

= ( x0 , x1 ,..., x n )

– вектор фазовых

T : {t 0 , t1 ,..., t m } – моменты времени).

Применительно к принятой системе нотаций закон эволюции представляет собой набор уравнений потоков:

Fond t = Fond t −1 + dt ⋅ Temp + − dt ⋅ Temp −

Fond t −1 – значение уровня в предыдущий момент времени, Temp + – наполняющие уровень потоки, Temp − – исчерпывающие уровень потоки. где

Fond t

,

– значение уровня в момент времени t,

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

154

Труды конференции Телематика’2010

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

yν

с переменными состояния

yν −1

предыдущей стадии

ν −1

ν

и с выбранным управлением

uν . В

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

(u1 ,..., u l ) , l

– число управляющих

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

f

управляющих параметров) нужно вычислить функцию приспособленности

. В роли функции

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

N /2

пар и к каждой из этих пар с вероятностью кроссинговера

Pk

применяют оператор кроссинговера. В данной работе применялся одноточечный кроссинговер (бинарная рекомбинация). Приведем общий алгоритм поиска оптимального управления: 1. Обратный ход схемы Беллмана (производится m раз, m – число шагов моделирования):

u1 ,..., u N

на данном

1)

Случайным образом генерируется начальная популяция управлений

2)

шаге. Размер популяции N задается пользователем. Для каждого управления из начальной популяции для всех возможных значений переменной

y m−1 Qm ( y m−1 , u m ) .

состояния

3) 4)

рассчитываются

соответствующие

значения

целевой

функции

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

N раз проводим операцию выбора родителей, кроссовера, мутации. 5) 6) Повторяем шаги 2–4, пока не будет выполнен критерий останова генетического алгоритма. Для каждого возможного состояния сохраняем значение условно оптимального управления и соответствующее значение целевой функции. После выполнения попятной процедуры получаем зависимости оптимальных управлений от любого возможного входа первой стадии, которые отражены в таблице 1. 2. Прямая процедура схемы Беллмана. 1) Находим состояние входа первой стадии в соответствии с минимальным (максимальным) значением функции 2)

Q1k , k = 1, n , n

– число состояний.

Находим оптимальные управления на всех стадиях процесса.

155

Таблица 1. Структура данных о состояниях на всех шагах в схеме Беллмана

Номер состояния

Номер шага

0

1 Q01 , u 1опт0

... ...

i i Q0i , u опт 0

i+1 i +1 Q0i +1 , u опт 0

... ...

m m Q0m , u опт 0

Q11 , u 1опт1 ...

... ...

m Q1m , u опт 1 ...

...

i +1 Q1i +1 , u опт 1 ... i +1 Qki +1 , u оптk

... ...

Q1k , u 1оптk

i Q1i , u опт 1 ... i Qki , u оптk

...

m Qkm , u оптk

Q1k +1 , u 1оптk +1

...

i +1 i +1 i Qki +1 , u оптk +1 Q k +1 , u оптk +1

...

m Qkm+1 , u оптk +1

... Qn1 , u 1оптn

... ...

... i Qni , u оптn

... ...

... m Qnm , u оптn

1 ... k k+1 ... n

... i +1 Qni +1 , u оптn

Поиск условно оптимальных управлений в обратной процедуре можно производить одновременно на нескольких вычислительных устройствах. Для этого на каждом шаге обратного хода метода Беллмана набор состояний ранжируется по номерам узлов и в процессы передаются соответствующие массивы значений состояний. Затем производится параллельное вычисление значений целевой функции. Таким образом, оптимальные значения параметра-критерия вычисляются гораздо быстрее. Апробация методики проводилась на примере задачи распределения ресурсов. Была составлена модель работы некоторого предприятия, выпускающего три вида продукции в течение пяти лет. Количество переменных фондов получилось равным 22, темпов – 37, констант – 29. Для модели было выбрано 4 переменных состояния и 6 управляющих параметров. Реализация параллельного алгоритма проводилась с помощью MS-MPI (Microsoft HPC Pack 2008 SDK). В таблице 2 приводятся значения времени работы алгоритма для последовательной и параллельной реализаций в зависимости от числа особей в популяции генетического алгоритма для 1296 возможных состояний. График зависимости времени работы от размера популяции приведен на рис. 1. Генетические алгоритмы обладают мощным внутренним параллелизмом, поэтому следующим шагом в модификации данной системы может стать распараллеливание самого генетического алгоритма с помощью «островной» модели, когда каждый вычислительный узел обрабатывает независимые популяции особей (взаимодействие между островами осуществляется с помощью механизма миграций). Таблица 2. Сравнение времени работы последовательной и параллельной реализаций алгоритма Размер популяции

156

Время работы на одном узле, с

Время работы на двух узлах, с

Ускорение

4

29,14

18,082

1,61

6

57,51

35,58

1,61

8

103,965

60,99

1,70

10

164,663

95,651

1,72

12

254,56

141,922

1,79

14

416,376

227,75

1,82

Труды конференции Телематика’2010

Рис. 1. Зависимость времени работы алгоритма от размера популяции Разработка информационной системы поддержки принятия решений в многоэтапном распределении ресурсов Рассмотрим распределение средств в учреждении, выполняющем финансируемые научноисследовательские работы (НИР). Такие виды работ завершаются получением строго формализованных результатов (количество публикаций, защит диссертаций и т.д.). Для простоты в качестве такого учреждения определим подразделение вуза, способного привлекать средства для выполнения НИР. Результаты, описываемые в работе можно обобщить и для вуза в целом, а также любого предприятия, основной приоритет которого – результат (в действительности любое предприятие, или организация осуществляет свою деятельность в целях получения прибыли; но часто эта прибыль зависит от качественных характеристик выпускаемой продукции – результата). Так как мы имеем многошаговую задачу, то для ее решения используем схему Беллмана. Запишем рекуррентное соотношение Беллмана:

Wk (S k ) = max(w(S k , pk ) + Wk +1 (ϕ ( pk , S k ))) ,

(1)

pk

где состояние системы

Sk

– объем финансирования в текущем году,

показателей активности на текущем и последующих шагах,

w(S k , pk )

Wk (S k )

– сумма

– показатель активности

Wk +1 (ϕ ( pk , S k )) – сумма активностей на всех следующих шагах, ϕ ( pk , S k ) – функция получения состояния S k +1 от состояния S k и распределения pk . Функцию получения нового состояния ϕ ( pk , S k ) = S k +1 определяет многофакторная модель, определяющая

подразделения на

k -м

шаге,

связь финансирования НИР от ее результатов, т.е.

S k +1 = ϕ ( x1 , x2 ,..., xn ) = a0 + a1 x1 + a2 x2 + ... + a µ xµ ,

где

xl = ∑ v j xljmax ∏ f slj ( pks )

(коэффициенты

η

3

j =1

s =1

al

– объем полученного результата

l -го

типа в

k -ом

году

определяются путем регрессионного анализа).

С математической моделью подробно можно ознакомиться в работах [1, 2]. Схема Беллмана делится на два этапа: обратный ход и прямой ход. На каждом шаге обратного хода

S k , задав максимальный предел финансирования S max и количество Для каждого такого уровня мы находим величину Wk (S k ) , исходя из

мы дискретизируем состояние уровней финансирования.

157

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

p1k , p2 k , p3k .

Таким образом, для расчетов нам необходимо хранить следующие данные (табл. 3): Таблица 3. Структура данных состояний в схеме Беллмана на всех шагах

Номер состояния

Номер шага

1

…

i

0

…

S i +1 , pi* ,Wi *

S i + 2 , pi*+1 ,Wi +*1 …

1

S 2 , p1* ,W1* … S i +1 , pi* ,Wi *

S i + 2 , pi*+1 ,Wi +*1 …

…

…

…

k

…

S i +1 , pi* ,Wi *

S i + 2 , pi*+1 ,Wi +*1 …

k+1

…

S i +1 , pi* ,Wi *

S i + 2 , pi*+1 ,Wi +*1 …

…

…

…

…

…

M

…

S i +1 , pi* ,Wi *

S 2 , p1* ,W1*

…

t m+1 = 0 , начальный объем финансирования S1 . Эффективность на шаге

i+1

…

…

…

tm

pt* , w* ( pt* , S t pt* , w* ( pt* , S t m

m

m

m

m

m

…

pt* , w* ( pt* , S t m

m

m

m

) )

m

)

pt* , w* ( pt* , S t m

m

…

pt* , w* ( pt* , S t m

) )

m

а на первом шаге у нас задано единственное состояние –

Для ускорения работы информационной системы был применен принцип распараллеливания схемы Беллмана, описанный выше. Для апробации методики были взяты данные за семилетний период работы одного из подразделений университета. Программное обеспечение было протестировано на компьютере Intel(R) Core(TM) i7 CPU 920 @2.67 GHz. Реализация параллельного алгоритма проводилась с помощью MS-MPI (Microsoft HPC Pack 2008 SDK). Результаты тестов приведены на рис. 2.

Рис. 2. Коэффициент ускорения работы программы при применении параллельных вычислений

158

Труды конференции Телематика’2010

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

2.

Шленов, Ю.В. Разработка научно-методического обеспечения долгосрочного планирования бюджета организации в целях повышения эффективности ее деятельности / Ю.В. Шленов, С.М. Аракелян, А.В. Духанов, О.Н. Позднякова, В.Г. Прокошев // КАЧЕСТВО. ИННОВАЦИИ. ОБРАЗОВАНИЕ. – 2008. – №8. – С. 15–19. Позднякова О.Н., Духанов А.В. Повышение эффективности распределения финансовых фондов вуза с применением математического моделирования и методов оптимизации // Молодые исследователи регионам: Материалы Всерос. науч. конф. студ. и асп. В 2-х т. – Вологда, ВоГТУ, 2007 – Т.2, C. 243–246.

ПАРАЛЛЕЛЬНЫЙ КОД ДЛЯ МОДЕЛИРОВАНИЯ ДИНАМИКИ СВЕРХЗВУКОВОГО ГАЗА С САМОГРАВИТАЦИЕЙ C.А. Хоперсков, М.А. Еремин, А.В. Хоперсков Волгоградский государственный университет E-mail: [email protected] Численная схема. Решение уравнений газовой динамики Разработана и реализована конечно-объемная численная сеточная схема для решения уравнений динамики газа с учетом внешних сил и самогравитации. Алгоритм расчета адаптирован на случай наличия в расчетной области границы раздела газ-вакуум. Расчеты демонстрируют универсальность и адекватность построенной схемы для моделирования как сложных стационарных, так и нестационарных течений, включающих гидродинамические разрывы и развитие неустойчивостей (неустойчивость Кельвина-Гельмгольца, гофрировочная неустойчивость). Запишем систему уравнений гидродинамики в дивергентной форме:

dU +∇⋅F = S , (1) dt где U = [ ρ , ρv1 , ρv 2 , ρv 3 , E ] – вектор физических величин, S = [0, ρ f , ρ v ⋅ f ] – вектор источников, F = [ ρ v, ρ v ⋅ v + pIˆ, ( E + p )v ] – вектор потоков, Iˆ = diag[1,1,1] , t – время, ρ – объемная плотность газа, 2

E = ρ (e + v / 2)

p

– давление,

v = [v1 , v2 , v3 ]T

– вектор скорости,

f

– вектор внешних

e – удельная внутренняя энергия. Для идеального газа справедливо уравнение состояния e = p /[ ρ (γ − 1)] , γ – показатель адиабаты.

сил,

– полная энергия,

Система (1) является системой уравнений в частных производных гиперболического типа. Дополним ее граничными и начальными условиями:

⎧U (t , G ) = U ( g ), ⎨ ⎩ U (0, G ) = U 0 , где

G

– расчетная область,

g

(2)

– граница расчетной области.

Для решения системы уравнений (1) была реализована и распараллелена явная трехмерная TVD (Total Variation Diminishing) схема типа MUSCL (Monotone Upstream-centered Schemes for Conservation Laws). Этот подход удовлетворяет условию невозрастания полной вариации, сохраняет монотонность численного решения для большинства задач, нет необходимости вводить искусственную вязкость, а также характеризуются отсутствием нефизичных осцилляций на разрывных решениях [1]. Численный метод был построен для цилиндрической системы координат. Для дискретизации был выбран, не конечно-разностный подход, а наиболее эффективный интегроинтерполяционный (метод конечных объемов), в этом случае законы сохранения выполняются на сеточном уровне [2]. При этом значения сеточных функций заменяются средними значениями по объему ячеек, а производные вычисляются по функциям на границах ячеек. Конечно-объемная аппроксимация 159

физически величин также позволяет избегать особенностей при r=0. Также использовался третий порядок аппроксимации величин по пространству. Продвижение по времени целесообразно вести с помощью быстрого явного метода, который бы не понижал точность численной схемы. Наиболее удобен метод Рунге-Кутта второго порядка точности. В рамках двухшагового шаблона продвижения по времени на подшаге предиктор вычисляются значения n

физических величин

U ijk

для фиктивного временного шага

фиктивного временного шага можно найти усреднением

t + 2∆t

–

U

(

n +1

( n + 2 )* . ijk

Величины на реальном временном слое ( n + 2 )*

n

U ijk = 0.5 ⋅ U ijk + U ijk Шаг по времени имеет вид

где объема,

C <1

–

∆t

t + ∆t . Тогда на подшаге корректор для

)

n +1 (3)

ограничивается условием устойчивости типа Куранта-Фридрихса-Леви, которое

∆lijk2 ∆lijk3 ⎞ ⎛ ∆lijk1 ⎟⎟ , , , ∆t = C ⋅ min⎜⎜ v c v c v c + + + | | | | | | s 2 s 3 s ⎠ ⎝ 1 1 2 3 число Куранта, ∆l ijk , ∆l ijk , ∆l ijk – линейные размеры

(4)

элементарного конечного

c s − адиабатическая скорость звука. Таким образом, численный расчет ведется с переменным

шагом интегрирования, зависящим от процессов, протекающих в газовой подсистеме. Для вычисления потоков физических величин через границы ячеек будем использовать решение задачи Римана, на котором основаны так называемые методы Годунова [3]. Использование точного решения задачи Римана является крайне ресурсоемким, поскольку требует в каждой ячейке расчетной сетки решения нелинейного алгебраического уравнения. Воспользуемся приближенным подходом, основанным на модифицированном методе Хартена-Лакса-ван Лиира (HLLC), который позволяет одновременное учитывать наличие ударных волны, контактных и тангенциальных разрывов [4]. Данный метод был модифицирован для сквозного расчета границы газ-вакуум, что является важной особенностью для моделирования астрофизических систем, в которых могут возникать области крайне низкой концентрации вещества. Численная схема. Решение уравнения Пуассона Для учета эффекта самогравитации в газе необходимо дополнить правую часть уравнения Эйлера в системе (1) уравнением Пуассона

∆Ψ = 4πGρ ,

где

Ψ = −∇ f

– внешний потенциал,

G

(5)

– гравитационная постоянная.

Для решения уравнения Пуассона (5) был реализован алгоритм типа TreeCode. Метод можно разбить на два этапа: построение дерева взаимосвязей для каждой частицы (ячейки) и суммирование сил для каждой их них. Алгоритм работает за счет группировки частиц (для решения уравнения (5) на структурированной сетке – это узлы ячеек, но в общем случае частицы расположены в расчетной области произвольно) с помощью иерархии кубов, организованных по структуре окто-дерева, т.е. каждый узел в дереве имеет 8 ответвлений. Самый верхний в дереве куб включает в себя все частицы. Далее этот основной куб равномерно делится на восемь одинаковых кубов, каждый из которых содержит свое подмножество частиц. Затем для каждого из кубов второго поколения производится новое деление на восемь кубов, в каждом из которых расположены различные частицы. Этот процесс проводится до тех пор, пока на самом нижнем уровне, в каждом кубе не останется по одной частице. Для каждого куба в дереве, содержащего частицы, мы рассчитываем центр масс, полную массу и моменты высшего порядка мультипольных разложений (как правило, лишь до квадрупольного порядка). На втором этапе происходит суммирование сил, действующих на каждую ячейку со стороны всех остальных. На каждом уровне построенного дерева частица взаимодействует напрямую с частицами, находящимися с ней в одном кубе, к чему добавляются взаимодействия этой частицы с остальными кубами того же уровня дерева. При этом центры масс этих кубов должны быть не дальше некоторого расстояния. Далее вычисления переходят на следующий уровень дерева. Если линейный размер куба –

l , а расстояние от частицы до его центра масс – частицы с кубом, если: где

Θ

d > l /Θ,

(6)

– параметр, чем меньше его величина, тем точнее рассчитывается взаимодействие. Можно

показать, что при 160

d , то мы учитываем гравитационного взаимодействие

Θ = 1 , ошибка в величине силы достигает 1%.

Труды конференции Телематика’2010

Такой метод позволяет быстро рассчитывать гравитационное взаимодействие между узлами расчетной сетки при газодинамическом моделировании. Решать уравнение Пуассона необходимо как минимум один раз на каждом шаге интегрирования системы уравнений (1), поэтому крайне важна скорость вычисления гравитации. Распараллеливание численного алгоритма Распараллеливание численного кода выполнялось с помощью одновременного использования стандартов MPI и OpenMP. Заданная расчетная область распределялась между процессорами. Декомпозиция на подобласти проводилось вдоль всех трех координатных осей: вдоль радиуса, вдоль угла и вдоль вертикального направления. В начальный момент времени строится пространственное распределение газа и его скоростей локально на каждом процессе, что обеспечивает экономию оперативной памяти при расчетах с высоким пространственным разрешением. Для визуализации начального течения и результатов последующей эволюции газа, необходимо собрать все значения физических величин на один процесс и сохранить в файл. Была реализована достаточно эффективная методика, при которой на главный процессор данные с каждого процесса отправляются по столбцам, после чего одномерный массив данных сохраняется на жесткий диск. При этом на главном используется алгоритм, позволяющий организовать данные в формате удобном для считывания в графических средах (Matlab, TecPlot или ParaView). Для получения решения во всей расчетной области необходимо обеспечивать непрерывную связь соседних процессов за счет обмена данными в фиктивных граничных ячейках. Т.к. разработанная численная TVD схема имеет третий порядок аппроксимации по пространству, то соседним процессам необходимо обмениваться всеми физическими величинами, находящимися в двух приграничных слоях ячеек. В силу того, что данные граничных ячеек расположены в памяти непоследовательно, то вдоль радиуса можно пересылать границу целиком (плоскость), вдоль угла последовательность одномерных массивов и вдоль вертикальной координаты – поэлементно. Таким образом, время обмена границами на каждом гидродинамическом шаге вдоль координатных осей относится как 1:2:10. Тогда для того, чтобы компенсировать потерю эффективности при пересылке граничных условий вдоль вертикальной координаты, то именно по этому направлению декомпозиция должна быть наименее подробной. Дальнейшей модификацией обмена границами стало последовательное объединение данных, необходимых для отправки, и их дальнейшая пересылка. Одним ограничением на способ декомпозиции расчетной области, возникающим в силу цилиндрической симметрии, является необходимость использования четного количества процессов вдоль разбиения по углу. Таким образом, при обмене внутренней границей (при r = 0) более каждому процессу необходимо и достаточно передавать (и принимать данные) одному процессу. Если разбиение на нечетное количество, то каждый процесс связан общей границей с двумя другими процессами.

Рис. 1. Распределение времени расчета на одном газодинамическом шаге: • 15% – расчет потоков физических величин (плотность, давление и 3 компоненты скорости) и вычисление новых значений в узлах ячеек расчетной сетки. • 35% – построение деревьев взаимодействий для каждой ячейки и их рассылка на процессы. • 45% – суммирования взаимодействий ячеек (вычисление гравитационных сил). • 5% – перерасчет внешнего потенциала, определение шага интегрирования, сбор данных на главном процессе для построения дерева взаимодействий. Для вычислительных кластеров, состоящих из многоядерных процессоров, эффективным оказалось использование стандарта OpenMP внутри каждого процесса. В этом случае происходит ускорение из-за отсутствия необходимости производить обмен фиктивными ячейками. Структура численного 161

газодинамического кода позволяет распараллелить вычисления с помощью OpenMP в течение всего времени расчета на каждом процессе, за исключением сохранения состояния системы на жесткий диск. В численном гидродинамическом алгоритме также проведена оптимизация распараллеливания за счет использования неблокирующей пересылки данных стандарта MPI [5]. Алгоритм расчета самогравитации занимает значительно больше времени, нежели вычисление газодинамики на каждом шаге интегрирования (рис. 1), поэтому важно адаптировать решение уравнения (2) под параллельные вычисления [6]. Самогравитация рассчитывалась в три этапа: 1. Построение дерева зависимостей на главном процессоре. Для этого необходимо перед началом расчета сохранить координаты ячеек со всех процессоров, эти данные остаются неизменными на протяжении всего расчета. Далее на каждом шаге интегрирования необходимо собирать плотности (или массы) всех ячеек расчетной области на главном процессе. После чего происходит уже описанное выше построение дерева кубов, для каждой ячейки процесса. Эти действия производятся с помощью рекурсивных операций и крайне трудны в распараллеливании. Однако эти действия занимают порядка 3–5% от времени расчета одного шага интегрирования. 2. Для каждой ячейки расчетной области на втором этапе установлены все необходимые данные для вычисления гравитационной силы, действующей на нее со стороны остальных ячеек. Проводится рассылка данных на каждый процессор, необходимых для вычисления гравитации для ячеек на данном процессоре. Время, затрачиваемое на этот этап, зависит от

3.

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

Эффективность распараллеливания составляет 60–90% в зависимости от конфигурации кластера, на котором проводятся вычисления и от особенностей моделируемых газодинамических процессов. На рис. 1 показано, какую часть одного шага интегрирования занимают различные этапы вычислений. Заметим, что наиболее ресурсоемким (до 80 %) является процесс вычисления гравитационных сил. Гравитационная неустойчивость в газовом диске Описанные выше численный код был использован для изучения гравитационной неустойчивости в галактическом газовом диске на начальных этапах эволюции галактики. Гравитационное взаимодействие между разными частями системы (самогравитация) сжимает вещество. Этот процесс называется гравитационной или джинсовской неустойчивостью. Он приводит к перераспределению массы: в одной области плотность растет, в другой, при отсутствии источников, уменьшается. Различные факторы противостоят самогравитации, другие способствуют ей [7]. С помощью численного моделирования было показано, что процесс гравитационной неустойчивости может приводить к формированию глобальных спиральных структур в газовом диске галактики, что во многом определяет морфологический тип моделируемой галактики. Найдены параметры газовой подсистемы, соответствующие тому или иному типу спиральных рукавов (например, количество спиралей 1, 2, 3, 4 …). На рис. 2 показано возмущение поверхностной плотности гравитирующего газового диска, которое демонстрирует формирование двухрукавной спиральной структуры под действием гравитационной неустойчивости. Численные расчеты были проведены с учетом следующих основных факторов: • самогравитация газа; • дифференциальное вращение газового диска; • осесимметричный внешний потенциал (темное гало); • радиальная неоднородность параметров газа (плотность, скорость звука); • вертикальная структура диска.

162

Труды конференции Телематика’2010

Рис. 2. Возмущение поверхностной плотности гравитирующего газового диска

Важнейшим параметром, отвечающим на вопрос устойчивости вращающейся газовой системы, является параметр Тоомре

QT

[8], который для газа можно представить в виде:

QT = где

r

– радиальная координата,

эпициклическая частота,

c r (r )

cr (r )k (r ) 3.36σ (r ) – скорость звука в диске,

σ (r ) - профиль поверхностной плотности.

(7)

r ∂Ω k (r ) = 2Ω 1 + Ω 2 ∂r

–

С помощью численных моделирований были найдены значения параметра Тоомре, соответствующие границам гравитационной неустойчивости для двух- и трехрукавных спиральных структур. Авторы благодарят А.В. Засова и В.И. Корчагина за многочисленные обсуждения. Численные расчеты проводились на суперкомпьютере СКИФ-МГУ «Чебышев» при поддержке А.В. Засова и Н.В. Тюриной, а также вычислительном кластере кафедры ИСКМ (ВолГУ, 40 ядер). Работа выполнена в рамках грантов РФФИ 09-02-97021, 10-07-97017, ФЦП 2009НК-21(7). Литература 1. 2. 3. 4. 5. 6. 7. 8.

Harten A. High resolution schemes for hyperbolic conservation laws // Journal of computational physics, 1983, V. 49, P. 357–393. Куликовский А.Г., Погорелов Н.В., Семенов А.Ю. Математические вопросы численного решения гиперболических систем уравнений. – М.: Физмалит, 2001. van Leer B. Towards the ultimate conservative difference scheme. V. A second order sequel to Godunov's methods // Journal of Computational Physics, 1979, V.32, P. 101–136. Shengtai Li. An HLLC Riemann solver for magneto-hydrodynamics // Journal of computational physics, 2004, V. 203, P. 344–357. Антонов А.С. Параллельное программирование с использованием технологии MPI // М.: МГУ, 2004. – 71 с. C.-O Ahn, S.H. Lee, A new treecode for long-range force calculation. // Computer Physics Communications, 2008, 178, 121–127. Засов А.В. Физика галактик. // М.: Изд-во МГУ, 1988. Поляченко В.Л., Поляченко Е.В., Стрельников А.В. Критерий устойчивости для газовых самогравитирующих дисков. // ПАЖ, 1997, т.23, С. 551–560. 163

АРХИТЕКТУРА СИСТЕМЫ АВТОМАТИЗИРОВАННОГО АНАЛИЗА UPCПРОГРАММ Н.Е. Андреев Кемеровский государственный университет E-mail: [email protected] Введение Главное преимущество параллельных вычислительных систем заключается в поддержке одновременного выполнения параллельных операций с целью достижения высокой производительности. Получение высокой эффективности в процессе выполнения программы еще более усложняет использование параллельных систем. Согласно отчету Межведомственной комиссии по развитию сверхмощных вычислений США эффективность современных параллельных систем находится ниже отметки в 10% [1]. Постоянные технологические улучшения микропроцессоров приводят к резкому росту теоретической пиковой производительности. В результате мы получаем все менее сбалансированные мультипроцессоры, в которых с каждым годом растет дисбаланс между скоростью процессоров и пропускной способностью памяти. Этот дисбаланс приводит к низкому росту производительности на реальных приложениях. В условиях исключительно низкой эффективности приложений программистам необходимы инструменты анализа и оптимизации программ. Разработка и реализация таких инструментов для параллельных компьютеров очень сложна ввиду как архитектурной, так и эксплуатационной сложности таких систем. Инструменты анализа производительности, такие как KOJAK [2] и TAU [3], доказали свою полезность в вопросах анализа критичных ко времени приложений. Упрощая процесс установки замеров внутри программного кода, систематизируя данные о производительности в информативных диаграммах, давая возможность выявлять узкие места программы, эти инструменты значительно сокращают время, необходимое для анализа и оптимизации параллельных программ. Тем не менее, большинство таких инструментов работают с ограниченным набором программных моделей, преимущественно моделью передачи сообщений. В результате разработчики, использующие новые модели параллельного программирования, зачастую вынуждены вручную выполнять трудоемкий анализ при оптимизации своей программы. Хотя определенная работа в этом направлении была выполнена, подавляющее большинство новых моделей программирования не поддерживаются инструментами анализа производительности ввиду значительного объема работы, необходимого для включения поддержки новой модели. В частности, модель разделенного глобального адресного пространства (PGAS), которая, несмотря на рост популярности и использование в ряде крупных проектов, например, расчетах, выполняемых исследовательским центром армии США [4, 5], в данный момент не представлена среди инструментов анализа производительности. В данный класс входят языки Unified Parallel C (UPC) [6], Titanium [7] и CoArray Fortran (CAF) [8]. Также необходимо заметить, что большинство существующих инструментов используют ручной метод анализа, где пользователь должен самостоятельно выполнять поиск узких мест производительности приложения на основе представленных диаграмм, графиков, таблиц и методов манипулирования ими (масштабирование и поиск). Представление информации о производительности программы в графическом виде может быть мощным приемом, но без сложных методов фильтрации объем отображаемых данных может быть чрезвычайно большим, что сильно снижает полезность подобных инструментов. В данной работе предлагается использовать автоматизированный анализ производительности, где система сама находит узкие места в приложении, а программисту остается лишь устранить их. Архитектура системы Данная работа посвящена разработке системы автоматизированного поиска шаблонов неэффективного поведения параллельных программ для программной модели разделенного глобального адресного пространства (PGAS). В частности, для языка Unified Parallel C (UPC). Традиционная модель передачи сообщений, реализованная в MPI, доминирует сегодня в области крупномасштабных параллельных комплексов. Тем не менее, ограничения этой модели, которые значительно снижают продуктивность разработки, широко признаны, поэтому PGAS модели набирают популярность [9]. Обеспечивая абстракцию общего адресного пространства для разнообразных системных архитектур, эти модели позволяют разработчикам выражать межпроцессные коммуникации подобно традиционному программированию с общей памятью, но с явным семантическим указанием локальности (locality), что позволяет добиться высокой производительности на системах с распределенной памятью. Модель PGAS делает акцент на использовании односторонних коммуникационных операций, где при передаче данных нет необходимости в явном отображении на двухсторонние пары send и receive – трудоемкий, подверженный ошибкам процесс, серьезно влияющий на продуктивность программиста. В результате программы, написанные в этой модели, проще для понимания, чем MPI версии, и имеют сравнительную или даже более высокую производительность [10, 11].

164

Труды конференции Телематика’2010

Рис. 1: Цикл работы с системой Цикл работы с системой выглядит следующим образом (рис. 1). Программист компилирует программу, написанную на языке UPC, так как он привычно делает это, но используя вместо команды компилятора upcc скрипт tmupcc, который входит в состав системы. Данный скрипт, прозрачно для пользователя, добавляет в исходную программу измерительный код, который будет через специальную библиотеку сообщать о событиях, возникающих в процессе работы программы, и компилирует приложение. Далее программа запускается при помощи скрипта tmrun. В результате выполнения программы для каждой нити будут созданы собственные файлы трасс, которые в дальнейшем объединяются в общий файл с упорядочиванием событий по времени. Общий файл подается на вход в модуль анализа, который генерирует файл с результатами. Визуализация результатов выполняется при помощи визуализатора Cube из пакета Scalasca [12]. Рассмотрим более подробно каждый из этапов. 1. Оснащение Для того чтобы провести анализ производительности параллельного приложения, необходимо собрать подробную информацию о происходивших в процессе его работы событиях. Такими событиями могут быть: захват или освобождение блокировки, выполнение коллективной коммуникационной операции и так далее. Если в параллельном приложении возникает большое количество таких событий, то процесс трассировки может внести значительные накладные расходы на работу программы. Поэтому программисту предлагается воспользоваться средствами, которые позволяют гибко управлять механизмом так называемой «инструментовки» или другими словами, добавления дополнительного кода в программу, который сообщает о возникающих в ней событиях. На первом этапе, при помощи ключей скрипта tmupcc, программист указывает, какие классы событий его интересуют. По умолчанию программа компилируется с ключом --inst, который указывает, что программа пользователя должна сообщать обо всех системных событиях, поддерживаемых моделью PGAS. К ним относятся обращения к функциям языка UPC, а также односторонние коммуникационные операции, обращения к которым происходят неявно при изменении значений общих переменных. Если программист укажет ключ --inst-functions, то вместе с системными функциями в трассу попадет информация о вызовах пользовательских функций. Ключ --inst-local добавит сообщения о локальных обращениях к общим переменным программы. Если в программе есть функция, которая вызывается большое количество раз в процессе выполнения приложения, то для нее будет сгенерирована масса трассировочной информации. Если для программиста данная функция не представляет большого интереса с точки зрения анализа производительности, то он может воспользоваться директивами предкомпилятора “pupc off” и “pupc on”, разместив их соответственно до и после описания функции. Это позволяет снизить размер трассировочных файлов, а также возмущения в работе параллельной программы. Если необходимо избежать инструментовки определенного блока программы, то в начале и в конце данного блока помещается функция pupc_control() с аргументами 0 и 1 соответственно. Зачастую программы имеют сложную структуру, когда фазы программы нельзя четко разделить по функциям. Локализация проблемы производительности в такой ситуации может оказаться проблематичной. Для решения данной проблемы в системе предусмотрен ряд функций для самостоятельной генерации событий программистом: pupc_create_event(), pupc_event_start() и pupc_event_end(). Предположим, что в программе пользователя есть четко выделенные фазы работы алгоритма: инициализация, вычисления, обмен данными. При помощи функции pupc_create_event() можно создать три события, соответствующие каждой из фаз. Далее каждый из блоков исходного кода обрамляется функциями pupc_event_start() и pupc_event_end(). В визуализаторе фазы будут выглядеть так, как будто происходил вызов обычных функций языка C. 2. Измерение Непосредственный сбор сообщений, возникающих в процессе работы приложения, и их запись в файлы трасс выполняет трассировочная библиотека, которая связывается (link) с программой 165

пользователя в процессе компиляции и становится неотъемлемой частью общего приложения. Любой код, добавленный к основной программе, вносит накладные расходы на ее выполнение. Большие накладные расходы могут сильно исказить результат трассировки, что в свою очередь приведет к некорректным результатам при анализе. Поэтому главным требованием к таким библиотекам являются низкие вносимые накладные расходы. Основным источником накладных расходов при трассировке являются медленные операции дискового ввода/вывода. Есть несколько подходов к выполнению ввода/вывода (В/В). Одной из самых распространенных моделей является синхронный блокирующий В/В. В данной модели приложение из пространства пользователя (user-space) выполняет системный вызов, который приводит к блокированию программы. Это означает, что приложение блокируется до тех пор, пока не завершится системный вызов (данные будут переданы или возникнет ошибка). Программа находится в состоянии, когда она не потребляет ресурсов процессора и просто ожидает ответа. Менее эффективным вариантом синхронного В/В является синхронный неблокирующий В/В. В данной модели устройство открывается в неблокирующем режиме. Операции чтения и записи возвращают ошибку о том, что команда не может быть немедленно выполнена, а приложение должно периодически проверять завершение операции. Между проверками программа может выполнять вычисления. Другой разновидностью блокирующей модели является метод неблокирующего В/В с блокирующими уведомлениями. В данной модели инициируется неблокирующий вызов, а для проверки состояния дескриптора В/В используется блокирующая функция select. Данная функция интересна тем, что она может использоваться для нескольких дескрипторов одновременно. Для каждого дескриптора можно запросить уведомление о возможности записи данных, чтения или возникновении ошибки. Проблема с вызовом select в том, что он не очень эффективен сам по себе и не подходит для высокопроизводительного В/В. Наконец в модели асинхронного неблокирующего В/В вызов немедленно возвращает выполнение программе. Дальше приложение может выполнять вычисления, пока операция выполняется в фоновом режиме. Для уведомления о завершении операции может быть использован механизм сигналов или обратных вызовов (callback). Данный метод позволяет в одной и той же нити одновременно выполнять вычисления и несколько операций В/В. Пока выполняются одна или несколько медленных операций В/В, процессор может продолжать выполнять параллельную программу. В данной системе используется асинхронный неблокирующий В/В, как наиболее эффективный метод параллельного выполнения вычислений и записи данных на диск. Трассировочная библиотека оперирует двумя буферами, в которые по мере выполнения программы записывается информация о возникающих событиях. Когда первый буфер полностью заполняется, библиотека продолжает записывать данные во второй буфер, в то время как при помощи механизма асинхронного неблокирующего В/В данные из первого буфера записываются в фоновом режиме на диск. Программист с помощью ключа скрипта tmupcc может самостоятельно управлять размером буферов, снижая, таким образом, накладные расходы до минимума. Кроме механизмов двойной буферизации и асинхронного ввода/вывода в системе поддерживается запись на локальные диски вычислительных узлов и последующего перемещения всех файлов трасс на сетевую файловую систему после завершения параллельной программы. Это позволяет избежать задержек на передачу данных по сетевому протоколу NFS. 3. Анализ Главный интерес программиста в использовании инструмента анализа производительности – это выяснить, в каких местах параллельная программа работает не оптимально, где есть ресурс для ускорения. Анализатор выполняет такой анализ, используя в своей основе базу заранее запрограммированных шаблонов неэффективного поведения. То, как эти шаблоны представлены внутри системы, позволяет фиксировать сложные ситуации, не охватываемые широко распространенными профилировочными инструментами и визуализаторами трасс. Шаблоны – это составные события, то есть набор найденных в трассировочном файле вызовов, которые удовлетворяют условиям возникновения ситуации, описываемой шаблоном. Так как составные события обычно включают в себя сложные межсобытийные связи, необходимы высокоуровневые структуры данных, которые способны отслеживать и предоставлять в нужный момент такую информацию. Поэтому в экспертной системе предусмотрен не последовательный, а произвольный доступ к событиям в файле трассы и несколько видов мощных абстракций. Результатом работы анализатора являются найденные в программе соответствия шаблонам, то есть места их возникновения и неэффективно потраченное на них время. Программист просматривает результаты в графическом интерфейсе в виде куба. Это означает, что для исследователя данные представлены в виде трех измерений, каждое из которых организовано иерархически. Первое измерение – это метрики, те самые шаблоны, разбитые на группы (синхронизация, коммуникации и так далее). После выбора интересующей программиста метрики, он, во втором измерении, видит, в каких функциях и каких конкретно строках кода его программы, что не маловажно, эта метрика встречается. В третьем измерении можно увидеть, как возникновение данной метрики распределено по нитям и узлам кластера. В каждом измерении дается время, потраченное на данную метрику. Для первого измерения это будет общее время, для второго – время для конкретной функции и для третьего – время, потраченное в шаблоне данной конкретной нитью. В результате программист точно знает, где его программа ведет себя неэффективно. Все что ему остается – это оптимизировать программу в соответствии с полученной информацией.

166

Труды конференции Телематика’2010

Заключение Инструменты анализа производительности оказывают неоценимую помощь разработчикам параллельных приложений в оптимизации параллельного кода. Созданная в данной работе система имеет одно серьезное преимущество над подобными уже разработанными инструментами – она выполняет автоматизированный анализ и позволяет это делать для новой модели параллельного программирования с глобальным распределенным адресным пространством (PGAS). Для программиста это означает, что ему нет необходимости вручную просматривать длинные временные шкалы (timeline), как это происходит, например, в TAU. Это становится особенно актуальным в условиях постоянного роста количество ядер в современных кластерах и увеличения сложности параллельных комплексов. База знаний, лежащая в основе инструмента, заранее знает потенциальные узкие места, которые могут возникнуть в программе. Программист получает готовые подсказки и может немедленно приступить к оптимизации. Немаловажно также отметить, что данная система работает с языком Unified Parallel C, который является одним из представителей программной модели Partitioned Global Address Space – нового витка в развитии языков параллельного программирования. Литература 1.

Federal Plan for High-End Computing [Electronic resource] / Report of the High-End Computing Revitalization Task Force // http://www.nitrd.gov/pubs/2004_hecrtf/20040702_hecrtf.pdf. – 2004. – 10.04.2010. 2. Mohr, B. KOJAK – A Tool Set for Automatic Performance Analysis of Parallel Applications [Text] / B. Mohr, F. Wolf // Proceedings of the International Conference on Parallel and Distributed Computing. – 2003. 3. Malony, A.D. TAU: The TAU Parallel Performance System [Text] / S. Shende, A.D. Malony // International Journal of High Performance Computing Applications. – 2006. – 20:2. – P. 287-331. 4. Johnson, A.A. Unified Parallel C in CFD Codes [Text] / A.A. Johnson // Army HPC Research Center Bulletin. – 2004. – V. 14. – N. 4. 5. Johnson, A.A. Developing a Petascale Application Using UPC [Text] / A.A. Johnson // Army HPC Research Center Bulletin. – 2005. – V. 15. – N. 3. 6. UPC Language Specifications v1.2. [Text] / UPC Consortium // Lawrence Berkeley National Lab Tech Report LBNL-59208. – 2005. 7. Aiken, A. Titanium: A High-Performance Java Dialect [Text] / A. Aiken, et al. // Concurrency: Practice and Experience. – 1998. – 10:11. – 13. 8. Numrich, B. Co-Array Fortran for Parallel Programming [Text] / B. Numrich, J. Reid // ACM Fortran Forum. – 1998. – 17:2. – 1-31. 9. High Productivity Computing Systems [Electronic resource] / DARPA, et al. // http://www.highproductivity.org/. – 2004. – 10.04.2010. 10. Bell, C. Optimizing Bandwidth Limited Problems Using One-Sided Communication and Overlap [Text] / C. Bell, D. Bonachea, R. Nishtala, K. Yelick // 20th International Parallel & Distributed Processing Symposium. – 2006. 11. Datta, K. Titanium Performance and Potential: an NPB Experimental Study [Text] / K. Datta, D. Bonachea, K. Yelick // Languages and Compilers for Parallel Computing. – 2005. 12. Geimer, M. The Scalasca Performance Toolset Architecture [Text] / M. Geimer, F. Wolf, B. Wylie, E. Abraham, D. Becker, B. Mohr // Concurrency and Computation: Practice and Experience. – 22(6). – 702-719. – April 2010.

РАСПРЕДЕЛЕННАЯ СИСТЕМА АВТОМАТИЧЕСКОГО ОБНАРУЖЕНИЯ СЕМАНТИЧЕСКИХ ОШИБОК В MPI-ПРОГРАММАХ К.Е. Афанасьев, А.Ю. Власенко Кемеровский государственный университет E-mail: [email protected]; [email protected] 1. Введение Нет необходимости говорить о том, что в настоящее время тематике высокопроизводительных вычислений и технологиям параллельного программирования придается колоссальное значение. Высокопроизводительные вычислительные системы вошли в перечень критических технологий Российской Федерации. Во всем мире научные организации и технологические предприятия затрачивают огромные средства на приобретение суперкомпьютеров и вычислительных кластеров. Самым популярным инструментом создания приложений для кластерных систем на данный момент остается интерфейс MPI (Message Passing Interface) в различных реализациях. При создании MPI-приложения разработчики встречаются со многими трудностями, среди которых особо следует выделить отладку. Причина этого заключается в том, что при параллельном программировании появляются новые источники ошибок, связанные с взаимодействием одновременно работающих 167

процессов. К семантическим ошибкам, не свойственным последовательным программам, относятся потенциальные и реальные дедлоки, интерфейсные и межпроцессные гонки данных, неверное управление внутренними объектами MPI-реализации, некорректная работа с памятью, ошибки несоответствия в коммуникационных операциях и т.д. Все эти ошибки можно условно разделить на две категории: локальные, происходящие в пределах одного MPI-процесса, и глобальные, для обнаружения которых требуется анализ операций, выполненных несколькими процессами. Существует несколько подходов при создании программных средств, служащих в помощь разработчику в процессе обнаружения ошибок перечисленных типов. Автоматический анализ корректности параллельных программ во время исполнения имеет ряд преимуществ по сравнению с другими методами. Во-первых, посредством применения эвристических алгоритмов средство отладки может обнаружить ошибки, обусловленные недетерминизмом (потенциальные дедлоки и гонки данных). Во-вторых, для проведения анализа достаточно одного запуска параллельной программы и нет необходимости создавать программный код эталонной версии. Также не нужно составлять модель программы на каком-либо псевдоязыке и ожидать пока система произведет перебор всех вариантов исполнения параллельного приложения. В настоящее время существуют несколько систем этого класса (MARMOT, Intel Trace Analyzer and Collector – ITAC). Однако для обнаружения ошибок многих типов они используют довольно грубые методы (дедлоки ищутся по тайм-ауту, а заключение о возможности гонки данных выносится при наличии в программе макросов MPI_ANY_SOURCE и MPI_ANY_TAG), и кроме того, обе системы имеют существенные архитектурные недостатки. Так, в системе MARMOT [4] создается дополнительный процесс на одном из узлов вычислительного кластера, называемый Debug Server, который производит обработку ошибок всех типов. Если число ветвей MPI-программы достаточно велико, то Debug Server может стать узким местом, замедляющим работу остальных процессов. В системе ITAC [3] обнаружением всех типов ошибок занимаются дополнительные потоки, запускаемые в пределах каждого MPI-процесса. Такой подход оправдан при поиске локальных ошибок. Однако при проверке на наличие глобальных, данные потоки производят большое количество дополнительных пересылок друг другу, содержащих параметры, время вызовов и другую информацию. Подобный метод также нельзя признать эффективным. Таким образом, актуальной задачей на сегодняшний день представляется разработка информационной системы автоматического контроля корректности MPI-программ, способной масштабироваться на большое число вычислительных узлов и оказывающей минимальное влияние на производительность проверяемой параллельной программы. В связи с этим, на кафедре ЮНЕСКО по новым информационным технологиям Кемеровского государственного университета была поставлена задача создания распределенной масштабируемой системы автоматического контроля корректности MPI-приложений [1]. В Кемеровском государственном университете ведется разработка информационновычислительного портала (http://icp.kemsu.ru) [2]. Одной из его главных задач является предоставление пользователю возможности запуска параллельной программы на высокопроизводительных вычислительных ресурсах, используя web-интерфейс. Предусмотрена возможность работы с ресурсами, имеющими различные программные платформы. Работая в web-браузере, пользователь загружает на портал файлы исходного кода своего параллельного приложения. Следующий шаг – создание задания на компиляцию, выбирая требуемый компилятор и технологию параллельного программирования из списка имеющихся. Затем исследователь выбирает вычислительный ресурс и ставит в очередь задание на запуск. Сервер на портале работает с базой данных, хранящей информацию о пользователях, файлы исходного кода, исполняемые файлы, статус заданий, результаты расчетов и т.д. Очередное задание на запуск из базы выбирает менеджер вычислительных ресурсов, который передает расчет на один из имеющихся кластеров. На кластере работает агент, который запускает параллельное приложение и возвращает на сервер результаты работы. Для удобства пользователей систему автоматического контроля корректности MPI-приложений было решено интегрировать в портал. 2. Структура и принципы функционирования системы Подобно инструментальному средству MARMOT, предлагаемая система построена по клиентсерверной архитектуре, но кроме серверов анализ корректности проводят также дополнительные потоки, порождаемые в пределах MPI-процессов. Основу распределенной системы автоматического обнаружения семантических ошибок составляют: • несколько серверов-анализаторов, на каждом из которых запускается множество потоков (один поток обрабатывает сообщения от одного процесса MPI-приложения); • профилировочный интерфейс реализации MPI, посредством которого система получает информацию о вызываемых в программе MPI-функциях; • служебные потоки на вычислительных узлах, принимающие сигналы от анализаторов и проверяющих вызываемые MPI-функции на возникновение логических ошибок. Соответственно архитектуру системы можно представить следующим образом:

168

Труды конференции Телематика’2010

Рис. 1. Архитектура распределенной системы автоматического обнаружения семантических ошибок в MPI-программах Ниже приводится общая схема работы системы: 1. Создавая задание на компиляцию, пользователь определяет – желает ли он, чтобы запуск его программы на кластере был произведен под контролем системы автоматического обнаружения семантических ошибок. Если при заполнении формы пользователь указывает соответствующую галочку, то к его программе прилинковывается профилировочная библиотека. 2. Далее, определяя задание на запуск, среди прочих параметров пользователю необходимо выбрать количество серверов-анализаторов, которые будут анализировать MPI-программы на глобальные ошибки. 3. Агент, работающий на вычислительном кластере, получает от менеджера вычислительных ресурсов задание на запуск. Затем агент запускает по ssh на указанном пользователем количестве узлов программы-анализаторы, передавая им в качестве аргументов число процессов MPI-приложения. 4. После инициализации необходимых структур, запустившиеся серверы-анализаторы пассивно ожидают подключения от MPI-процессов. 5. Агент кластера запускает на вычислительных узлах процессы MPI-программы (для определенности будем считать, что на каждом из вычислительных узлов запускается по одному MPI-процессу). 6. При вызове первой же функции интерфейса MPI, которая должна присутствовать в любой программе, использующей данный интерфейс – MPI_Init, каждый из процессов параллельной программы посредством TCP-сокетов устанавливает соединение с соответствующим сервером-анализатором (ip-адреса серверов-анализаторов вычислительные узлы считывают из файла, хранящегося на агенте кластера). 7. На сервере для каждого подключения от MPI-процесса запускается по одному потоку, обрабатывающему сообщения от данного процесса. 8. Далее во время работы MPI-программы каждый вызов MPI-функции перехватывается профилировочной библиотекой, и аргументы вызванной функции передаются серверу. 9. Каждый поток на сервере-анализаторе в цикле принимает сообщения от вычислительного узла и помещает полученные данные в соответствующие структуры. На основе накопленной информации в данных структурах проводится анализ на возникновение глобальных семантических ошибок. 169

10. Кроме того, при вызове MPI-функции в очередь служебного потока поступает задание на поиск локальных ошибок. Подобно серверу-анализатору, служебный поток производит анализ по накопленным данным о предыдущих вызовах. 11. Найденные ошибки помещаются в списки, и по завершении работы MPI-программы происходит слияние со всех серверов и служебных потоков в файл журнала на одном сервере-анализаторе. 12. Вместе с файлами результатов журнал передается на агент кластера, откуда он поступает пользователю. 3. Алгоритм работы серверов-анализаторов Серверы-анализаторы обладают информацией обо всех коммуникационных функциях, вызываемых на вычислительных узлах. Поэтому они служат для поиска глобальных ошибок. Во время работы потоки на каждом из серверов используют следующие структуры данных: • Список вызванных MPI-функций типа точка-точка. Каждый из узлов списка содержит номер вызвавшего функцию процесса в глобальном коммуникаторе MPI_COMM_WORLD, имя вызванной операции, число передаваемых/принимаемых элементов, тип данных элементов, номер процессапартнера по коммуникации (отправителя или адресата соответственно), тэг сообщения, флаг завершенности операции (данный флаг показывает, поступило ли сообщение о завершении операции или нет) и контрольная сумма передаваемого/принимаемого буфера сообщения. Каждый сервер хранит свою копию данного списка и после внесения каждого изменения производится синхронизация списков на всех серверах. • Список незавершенных операций – заполняется при заключительном анализе параллельной программы. • Журнал найденных ошибок – частично заполняется по ходу исполнения параллельной программы и частично – по окончанию работы. Ниже подробно описан алгоритм обработки сервером сообщения, поступающего от вычислительного узла. 1. Производится разбор посылки (все сообщения с вычислительных узлов на серверы отправляются символьной строкой в едином формате) и определяется тот факт, является ли это сообщение сообщением о начале или окончании коммуникационной операции. 2. В случае если принято сообщение о начале коммуникации, в список вызванных операций типа точка-точка добавляется новый узел, куда записываются аргументы вызванной функции. Если же принято сообщение о завершении процедуры, то в списке вызванных операций отыскивается та, для которой данное сообщение является завершающим, и флаг завершенности операции данного узла списка устанавливается в значение «истина». Для неблокирующих коммуникаций сообщением о завершении считается посылка о выполнении функции MPI_Wait или функции MPI_Test с успешным результатом. Также при получении сообщения о завершении коммуникации в элемент списка вносится контрольная сумма пересылаемого/принимаемого буфера. 3. Информация об изменениях в списке рассылается по всем анализаторам и каждый из них проводит в своем списке аналогичные действия. 4. В случае если это сообщение о начале операции, для данного узла списка отыскивается парный. Парным считается узел, удовлетворяющий следующим условиям: имя функции соответствует противоположной операции (например, если данная функция – посылка сообщения, то отыскивается узел, соответствующий операции приема); номера отправителей и адресатов соответствуют друг другу или в операции приема указан макрос MPI_ANY_SOURCE; тэги операций совпадают или в операции приема указан макрос MPI_ANY_TAG. Если коммуникация была инициирована при помощи функции MPI_Bsend, то после того как сервер получит уведомление об окончании приема, он отсылает отправителю сигнал о завершении коммуникации. 5. Если найдены несколько парных узлов, то система делает вывод о появлении ошибки «гонка данных» и производит запись об этом в журнал ошибок. Такое может произойти, если, например, поступило сообщение от вычислительного узла n об операции приема с макросом MPI_ANY_SOURCE, а на нескольких других вычислительных узлах до этого были вызваны операции посылки узлу n, соответствующие по тэгу данной функции приема. 6. Контрольная сумма данного элемента списка сравнивается с контрольной суммой парного элемента и при несовпадении в журнал ошибок вносится запись о том, что передаваемый буфер был испорчен основной ветвью MPI-процесса по ходу коммуникации (такое может случиться при использовании неблокирующей операции). 7. Осуществляется проверка на наличие ошибок несоответствия в аргументах и в случае недополучения/недопосылки данных или несоответствия типов данных в журнал производится запись об этом. 8. Если после получения сообщения о начале коммуникации точка-точка вычислительным узлом истек заданный лимит времени, и не было получено сообщение о завершении операции, то выполняется проверка на возникновение дедлока. Дедлок при использовании посылок типа точка-точка определяется как появление ситуации, в которой каждый MPI170

Труды конференции Телематика’2010

процесс некоторого подмножества зависает в посылке (или приеме) сообщения другому процессу данного подмножества. То есть образуется кольцо процессов, в котором каждый пытается послать другому сообщение и не может дождаться начала приема для осуществления синхронной коммуникации. Обнаруживается дедлок путем поиска в списке отправленных сообщений такого кольца пересылок. То есть отыскивается элемент, соответствующий коммуникационной процедуре того же характера, что и анализируемая операция, вызванной процессом-партнером по анализируемой коммуникации. Если такой элемент списка обнаруживается, то список вновь просматривается на предмет наличия элемента, соответствующего незавершенной операции того же характера, вызванной процессом-партнером по отношению ко второй коммуникации и т.д. Если в итоге данного цикла обнаруживается, что очередной процесс вызвал коммуникацию того же характера, партнером для которой является исходный процесс, то делается вывод о возникновении дедлока и запись об этом вносится в журнал ошибок. Не все семантические ошибки в использовании MPI-стандарта можно обнаружить по ходу работы программы. Дополнительно требуется анализ состояния процессов на момент завершения приложения. Кроме того, по завершению работы приложения требуется выполнить ряд операций, приведенных ниже. Об окончании работы программы свидетельствует наступление одного из следующих событий: все MPIпроцессы передали анализаторам сообщения о вызове функции MPI_Finalize; до вызова MPI_Finalize последним процессом прошло время, превышающее лимит, заданный пользователем; некоторая группа процессов зависла в дедлоке, в то время как остальные послали сообщение о вызове MPI_Finalize. В случае наступления одного из этих событий серверы-анализаторы проводят следующие действия. 1. Просматривают список вызванных функций и находят беспарные коммуникации – те операции, для которых не было вызвано парных. Если таковые найдены, то анализируется журнал ошибок на предмет наличия в нем записей о дедлоках, в которых участвуют данные функции. При отсутствии соответствующей записи в журнал ошибок вносится сообщение о беспарной коммуникации. 2. Серверы делают еще один проход списка в поисках узлов, для которых флаг завершенности операции установлен в значение «ложь». Это означает, что для данной операции не поступало сообщение об окончании, а, следовательно, процесс завис в исполнении данной функции. 3. Если незавершенная операция найдена, то сервер просматривает журнал ошибок и при отсутствии записей о дедлоке или беспарной коммуникации с участием данной функции в список незавершенных процедур вносятся данные об этом элементе списка вызванных MPIфункций. 4. Последним действием на одном сервере-анализаторе собираются файлы журналов ошибок со всех серверов и служебных потоков, формируется единый журнал и передается агенту вычислительного кластера. 4. Алгоритм работы вычислительных узлов Основным средством, благодаря которому система автоматического контроля корректности получает информацию от исполняемой параллельной программы по ходу работы, является профилировочный интерфейс MPI-реализации. Вызываемые MPI-функции перехватываются статической библиотекой, которая и выполняет необходимые действия. В библиотеке заполняются структуры данных, проводится анализ и передача аргументов функции на сервер; потом вызывается соответствующая PMPI-функция, которая производит действия, требующиеся пользователю; затем снова проводится необходимая системе работа и результат PMPI-функции возвращается пользователю. В процессе анализа на наличие локальных ошибок в пределах каждого MPI-процесса используются следующие структуры: • Журнал ошибок – назначение данного объекта то же, что и на серверах-анализаторах. • Список активных «запросов обмена» - данные объекты используются в неблокирующих коммуникационных функциях для индикации завершенности этих операций. • Список используемых областей памяти – хранятся только для неблокирующих коммуникаций и служат для обнаружения ошибок повторного использования участков памяти MPI-функциями. • Список используемых буферов – содержат начальный и конечный адреса памяти для каждого буфера, выделенного операцией MPI_Buffer_attach. Служит для обнаружения гонок данных, связанных с затиранием буфера до окончания буферизованной коммуникации. • Очередь заданий на обработку для служебного потока, в которую при вызове очередной операции точка-точка помещается элемент, содержащий информацию о параметрах вызванной функции. Чтобы не загружать основной поток, выполняющий пользовательский расчет, при вызове MPI_Init порождается дополнительный, который в цикле проверяет очередь заданий на обработку и если очередь не пуста, то проводят анализ на появление локальных семантических ошибок. Обработка вызовов различных MPI-функций осуществляется по-разному. Здесь будет приведен лишь алгоритм обработки операций типа точка-точка. 1. Формируется и отправляется на сервер символьная строка, в которой один за другим следуют аргументы вызванной функции, а также некоторая служебная информация (номер 171

2.

3.

4.

5.

6. 7.

вызвавшего процесса; флаг завершенности операции, установленный в значение «ложь» и т.д.). В очередь заданий на обработку основной поток MPI-процесса помещает элемент, содержащий параметры функции и указатель на начало передаваемого/принимаемого буфера. В случае если вызвана неблокирующая функция, то в список активных запросов обмена служебный поток заносит запрос данной операции и проверяет ранее сделанные записи в списке на наличие запроса обмена, фигурирующего в данной процедуре. При обнаружении такового в журнал ошибок заносится запись о неверном управлении внутренними объектами интерфейса MPI. Впоследствии при вызове функции ожидания завершения неблокирующей операции (MPI_Wait) или успешного теста на завершение (MPI_Test) из списка активных запросов обмена данный элемент удаляется. Пару начальный-конечный адреса посылки служебный поток вносит в список используемых областей памяти, а затем просматривает список и если находит, что данный буфер пересекается с уже используемым какой-либо коммуникацией, то заносит в журнал ошибок данные об этом. Если вызвана буферизованная посылка, то в списке используемых буферов служебный поток ищет запись о буфере, задействованном в данной коммуникации, и если обнаруживает, что данный он занят, то в журнал ошибок вносит запись о повторном использовании буфера. Изначально в список заносится запись после соответствующего вызова MPI_Buffer_attach. А при вызове MPI_Bsend данный буфер помечается как занятый. По окончанию буферизованной коммуникации на узел-отправитель сервером отсылается сигнал об этом. Приняв данный сигнал, служебный поток помечает буфер как свободный. Вызывается соответствующая PMPI-операция, выполняющая необходимые пользователю действия. Вновь отправляется на сервер посылка с параметрами функции, за тем исключением, что флаг завершенности установлен в значение «истина».

Заключение В данной статье описана система автоматического контроля корректности MPI-программ, интегрированная в информационно-вычислительный портал КемГУ. Благодаря особенностям своей архитектуры – разделению работы по обнаружению логических ошибок между варьируемым числом серверов-анализаторов и служебными потоками на вычислительных узлах, система имеет потенциально неограниченную масштабируемость. Поскольку современные процессоры имеют несколько ядер, то основной поток, выполняющий MPI-процесс пользователя на вычислительном узле, может работать без ущерба в производительности. Действительно, служебный поток, производящий поиск локальных ошибок на каждом узле, работает на отдельном процессорном ядре, не мешая основному потоку. Также следует отметить малую дополнительную нагрузку на сетевой сегмент, создаваемую системой. Это обусловлено тем, что между вычислительными узлами и серверами-анализаторами циркулирует только информация об аргументах коммуникаций («метаданные» пересылок) и управляющие сигналы. В настоящее время разработаны алгоритмы для обнаружения семантических ошибок в коммуникациях точка-точка. Система отлавливает дедлоки; несоответствия в параметрах функций отправки/получения; гонки данных, обусловленные применением макроса «от любого процесса» в функции приема; изменение данных основным потоком в передаваемом буфере во время коммуникации; использование неосвобожденного скрытого объекта «запрос обмена» и использование уже задействованного в другой коммуникации буфера. Разрабатываемая система будет использоваться при запуске ресурсоемких численных расчетов на высокопроизводительных вычислительных ресурсах КемГУ в научных целях и в учебном процессе. Литература 1.

2.

3.

4.

172

Власенко, А.Ю. Модель масштабируемой системы автоматического контроля корректности параллельных программ. [Текст] / А.Ю. Власенко // Вестник НГУ. Т.7, выпуск 4, 2009. С. 53– 66. Григорьева, И.В. Система удаленного доступа и управления распределенными вычислительными ресурсами [Текст] / И.В. Григорьева, А.В. Демидов // Вычислительные технологии. Т.13, специальный выпуск 5, 2008. С. 28–32. Desouza, J. Automated, scalable debugging of MPI programs with Intel Message Checker [Текст] / J. Desouza, B. Kuhn, B. Supinski // Proceedings of the second international workshop on Software engineering for high performance computing system applications, St. Louis, Missouri. 2005. P. 78– 82. Krammer B. MPI Application Development Using the Analysis Tool MARMOT [Текст] / B. Krammer, M. Mueller, M. Resch // Lecture Notes in Computer Science. Vol. 3038. P. 464 – 471. Springer Berlin, 2004.

Труды конференции Телематика’2010

ОПТИМИЗАЦИЯ ПРОГРАММЫ МОДЕЛИРОВАНИЯ РАСПРОСТРАНЕНИЯ ВОЛНЫ ЦУНАМИ А.Ф. Зайков Новосибирский государственный университет E-mail: [email protected] Введение С давних пор жители прибрежных территорий оказывались подвержены атакам гигантских волн – цунами. Волны, внезапно поднимающиеся у побережья на высоту порой более 30 метров, могут наносить непоправимый ущерб строениям, коммуникациям и, что самое главное, жизни и здоровью многих людей. Так, цунами 24 декабря 2004 года, порожденное землетрясением возле берегов острова Суматра, унесло жизни более 230 тысяч человек по всему побережью Индийского океана. За всю историю человечества цунами унесли больше человеческих жизней, чем любое другое стихийное бедствие. Наиболее часто цунами возникают вследствие различных природных тектонических явлений, происходящих в океане. Цунами могут быть вызваны сильными землетрясениями и связанными с ними оползнями, извержениями вулканов, или прочими явлениями. При этом в эпицентре возникновения цунами волна поднимается на высоту всего несколько метров, поэтому в открытом океане волна почти незаметна, и не представляет опасности для кораблей. Однако скорость распространения волны может достигать 700 километров в час, и через несколько часов после возникновения волна может проявить себя на другом конце океана. При приближении к берегу скорость распространения волны уменьшается, и вследствие этого волна может подняться над поверхностью воды на несколько десятков метров, накатывая на побережье с огромной разрушительной силой. Разрушительная сила цунами настолько велика, что способов предотвращения или защиты от огромных волн просто не существует. В Японии, более всех государств подверженной риску со стороны океана, воздвигались различные защитные сооружения вроде мощных бетонных стен, однако подобные конструкции способны лишь уменьшить ущерб от небольших волн, против крупных цунами они бессильны. Единственным способом минимизировать ущерб от цунами является своевременное оповещение населения о предстоящей опасности и оперативные эвакуационные мероприятия. Подобная мера может значительно сократить число пострадавших, а также уменьшить материальный ущерб, наносимый этим природным явлением. Катастрофическое цунами 2004 года дало мощный толчок в развитии систем предупреждения цунами по всему миру, потому что задача минимизации ущерба от цунами достаточно сложна и многогранна. С одной стороны с момента возникновения цунами и до прихода волны к берегу может проходить несколько десятков минут. За это время надо исследовать параметры землетрясения, установить регионы, которые могут попасть в зону затопления, а также провести эвакуацию населения в безопасные районы. С другой стороны, далеко не каждое землетрясение может породить цунами, угрожающее прибрежным территориям. Например, цунами, зародившееся в феврале 2010 года возле берегов Чили, вызвало в Японии массовую эвакуацию населения в связи с тем, что службы предупреждения цунами предсказали появление большой волны. Однако, когда волна дошла до берегов Японии, высота воды поднялась не более чем на пол метра. В случае, если экстренные службы будут поднимать тревогу после каждого землетрясения, затраты на эвакуацию населения, на остановку производств будут превосходить все возможные убытки. Но большую опасность может вызвать тот факт, что население, недовольное частыми и неоправданными эвакуациями, перестанет реагировать на подобные предупреждения, что может привести к значительным человеческим жертвам в случае возникновения действительно опасного цунами. Поэтому перед службами прогнозирования и предупреждения цунами ставится задача получения оценки опасности, во-первых, наиболее точно, а вовторых, за кратчайшее время. Данная работа посвящена созданию программного средства для быстрого моделирования распространения волн цунами на основе программы расчета цунами из пакета MOST [1], а также переносу этой программы на многопроцессорные вычислительные системы над общей памятью с использованием механизма OpenMP. Математическая модель Математическая модель, заложенная в основу используемой программы, была разработана В. Титовым в 1988 году в Новосибирске [2]. В настоящее время программы, использующие эту модель, активно используются во всем мире для анализа распространения волн цунами. Модель основывается на нелинейной системе дифференциальных уравнений мелкой воды [3]:

173

Данная система преобразуется к каноническому виду, после чего применяется метод расщепления по пространственным переменным, как показано в [2]. В результате расщепления получаем две одинаковых независимых системы следующего вида:

Для численного решения этих систем использовалась явная разностная схема, которая имеет второй порядок аппроксимации по пространственным переменным, и первый по времени. Начальные условия представляют собой поле вертикальных смещений водной поверхности. На практике, как правило, значение имеет лишь амплитуда волн, поэтому выходными параметрами алгоритма также являются значения возвышения водной поверхности во всех узлах расчетной сетки в некоторые заданные моменты времени. Подготовка программы Первоочередной задачей проектирования программного продукта стал выбор языка программирования, на котором будет выполнен проект. Изначальные исходные коды программы из пакета MOST были написаны на языке Fortran-77. Однако, несмотря на то, что язык Fortran является одним из самых удобных языков для разработки программных продуктов, предназначенных для высокопроизводительных вычислений, было принято решение перенести исходный код на язык C. Язык C также позволяет получать высокую производительность от программных продуктов, однако не менее важным аргументом в пользу использования языка C стало то, что одним из перспективных направлений развития данного проекта является перенос программы под вычислительные платформы на базе NVidia CUDA и IBM Cell BE, а для этого язык C намного более удобен, чем Fortran. В процессе переноса основную проблему составляла задача тестирования правильности вычислений. Наиболее простым способом тестирования отлаживаемой программы на C было сравнение выходных результатов работы программ при запуске на входных данных, идентичных с входными данными для программы на Fortran. В результате данного этапа получены исходные коды программы на языке C, выдающие результаты расчета, сопоставимые с результатами работы исходной программы на Fortran. Среднее отклонение полученных значений от эталонных составляет менее 1%, что можно считать допустимым. В целом графики мареограмм для программ на C и на Fortran заметно приближаются, имеют пики возрастания одинаковой высоты, и времена появления волн отличаются незначительно. В процессе переноса кода дополнительно производилось сравнение производительности программ. Для компиляции программ использовался набор компиляторов GNU gcc + gfortran v4.3.3. В итоге время работы изначальной версии программы на Fortran оказалось немного меньше по сравнению со временем работы программы на C. Попытка использования компиляторной оптимизации привела к значительному уменьшению времени работы программы, однако скорость работы программы на C стала меньше скорости работы программы на Fortran совсем незначительно. Таким образом в данном случае компилятор языка C проигрывает по производительности компилятору языка Fortran незначительно. Ускорение программы: алгоритмические оптимизации Как уже упоминалось, для вычислений применяется метод разделения переменных. Согласно этому методу на каждой вычислительной итерации производится расчет распространения волны вдоль одной горизонтальной оси, а затем вдоль другой. Перед каждым расчетом вдоль одной оси реальные значения параметров волны в каждой точке моделируемого пространства переводятся к соответствующим римановым инвариантам, а после расчета снова возвращаются к изначальному виду. При этом фактически используемыми значениями являются четыре массива значений: глубина океана, толщина слоя воды и скорости вдоль двух координатных осей. Некоторые преобразования реализации данного алгоритма позволили заметно повысить скорость работы программы. В частности, для повышения локальности обращений к памяти после вычисления распространения вдоль одной координатной оси было предложено транспонировать массивы скоростей, глубины, толщины слоя воды. После выполнения вычислений вдоль второй координатной оси эти матрицы транспонируются снова. Эта операция затрачивает дополнительную часть процессорного времени, но заметно повышает скорость обращения к памяти. При этом итоговое сокращение времени, затрачиваемого на обращения к памяти, заметно превышает затраты времени на проведение транспонирования, при условии что размеры данных заметно больше, чем размер кэша процессора. Еще одним немаловажным шагом по оптимизации алгоритма вычислений стал вынос вычислений инвариантов за пределы вычислительного цикла. После выполнения данной оптимизации первое вычисление инвариантов производится до начала расчета вычислительных итераций, а в самом теле основного цикла используются только преобразования из инвариантов одного направления в инварианты другого направления. Преобразования к исходному виду производятся только для массива толщины слоя воды перед выводом результатов, а это требуется, как правило, не на каждом шаге. В результате проведенных оптимизаций скорость вычислений увеличилась с 3,72 вычислительных итераций в секунду для исходной программы на Fortran до 10,65 итераций в секунду для итоговой программы на C при счете на сетке размером 512x512. При этом среднее отклонение результатов 174

Труды конференции Телематика’2010

итоговых измерений составило менее 5% от результатов начальной версии программы на Fortran, что в данной предметной области считается вполне допустимым в силу специфики вычислительной задачи. Ускорение программы: оптимизация под вычислительную архитектуру Для получения высокой производительности зачастую оказывается полезно использовать специфику платформы, на которой будет использоваться программа. В нашем случае программа будет преимущественно использоваться на платформе процессоров Intel. Поэтому в процессе работы с программой было выполнено несколько шагов по оптимизации вычислений под данную платформу. Как было сказано выше, в процессе оптимизации алгоритма в вычислениях появились операции транспонирования больших матриц. Естественно, функция транспонирования этих матриц занимала довольно большую часть процессорного времени. Для того, чтобы сократить временные затраты на операцию транспонирования, собственная функция транспонирования была заменена на аналогичную функцию из библиотеки для высокопроизводительных вычислений Intel IPP. Однако большую часть процессорного времени все-таки занимают основные вычисления, рассчитывающие распространение волны. Эксперименты с подбором оптимальных опций компиляции не дали достаточно хороших результатов по ускорению этого участка вычислений, поэтому было принято решение произвести ручную векторизацию вычислений с использованием инструкций SSE. В итоге использование ручной векторизации с использованием инструкций SSE показало очень хорошее увеличение скорости вычислений, в два раза ускорив программу по сравнению с версией, над которой были произведены все оптимизации, кроме векторизации. Итоговая производительность программы выросла почти в четыре раза, сократив среднее время одной итерации с 3 секунд до 0,78 с при вычислении на сетке размеров 2579x2781. Ускорение программы: адаптация под многопроцессорные архитектуры Поскольку вычислительный алгоритм требует обмена довольно большого количества данных, схема вычисления с использованием распределенной памяти оказалась очень неэффективной [4]. Поэтому была применена модель программирования над системами с общей памятью с использованием OpenMP. Вычисления производились на вычислительной системе над общей памятью SMP 4 x Intel Xeon X7350 2.93 GHz с 16 вычислительными ядрами, предоставленной Сибирским суперкомпьютерным центром СО РАН. При компиляции использовался компилятор Intel icc v11.1. Помимо этого, измерения были проведены на сервере с процессором Intel Core i7 950 с 4 вычислительными ядрами. В результате распараллеливания производительность программы на процессоре Intel Xeon возросла с 1,28 итераций в секунду на одном ядре, до 5,84 итераций в секунду на 16 вычислительных ядрах, т.е. около 4,56 раз. При использовании процессора Intel Core i7 производительность на 1 ядре составляла 4,17 итераций в секунду, максимальная же производительность составила около 8,9 итераций в секунду на 4 ядрах. Причина таких результатов, по-видимому, заключается в том, что рассматриваемая задача очень сильно зависит от скорости обмена данными между процессором и памятью. Во-первых, данное объяснение хорошо согласуется с тем, что скорость работы программы на одном ядре на процессоре Intel Xeon в 3,2 раза больше, чем на одном ядре процессора Intel Core i7, несмотря на то, что частоты процессоров отличаются очень незначительно. Действительно, архитектура Core i7 позволяет намного более быстрый обмен данных между процессором и памятью из-за встроенного в процессор контроллера памяти, к тому же объем кэш-памяти уровня L3 процессора Core i7 вдвое больше объема кэш-памяти данного процессора Intel Xeon, и составляет 8 Мб. Во-вторых, вероятно, по этой причине происходит уменьшение производительности вычислений при использовании более 8 вычислительных ядер на 16-ядерной системе, поскольку разрешение зависимостей по данным между разными ядрами занимает больше времени. Таким образом, одним из возможных путей к дальнейшему повышению производительности программы может стать оптимизация обмена данных между процессором и памятью, что позволит эффективнее использовать программу на многопроцессорных системах. Точность вычислений Основная версия программы моделировала результаты с одинарной точностью вычислений. Однако получаемые результаты моделирования заметно отличались от ожидаемых. Было высказано предположение, что данное отличие возникало вследствие нехватки точности используемого формата данных. Для проверки предположения была создана альтернативная версия программы, использующая вычисления с двойной точностью. Сравнение результатов, получаемых программами с одинарной и двойной точностью, показало, что с течением времени в вычислениях с одинарной точностью накапливалось сильное расхождение результатов, по сравнению с программой с двойной точностью. Заметное различие происходило из того факта, что в вычислениях активно используется толщина слоя воды, представляющая из себя сумму из реальной глубины океана в данной точке и высоты волны. Среднее значение глубины Тихого океана – около 4 километров. При этом высота волны на достаточном удалении от источника может составлять несколько сантиметров. Таким образом, при вычислении общей толщины слоя воды q значение высоты волны сказывается лишь в 5-6 знаке мантиссы. Поскольку двойная точность хранения данных позволяет использовать мантиссу длиной около 16 знаков, а одинарная – до 7 знаков, то влияние высоты волны на всю толщину слоя воды оказывается довольно близко к пределу точности при вычислениях с одинарной точностью, по сравнению с двойной. 175

Чтобы избежать потери точности, был предложен следующий метод вычислений. Величина вертикального смещения воды в источнике умножается на некоторый коэффициент k. После получения результатов моделирования, вертикальные смещения воды уменьшаются в k раз. Таким образом, на момент вычислений влияние высоты волны смещается с 6 знака мантиссы, что заметно уменьшает влияние точности. Заметим, что данный метод не приводит к значительному изменению скорости распространения волны, поскольку при умеренном выборе коэффициента влияние на высоту столба воды остается в пределах 3-4 знака после запятой. Более детальные правила для выбора k будут исследованы в дальнейшем. Однако уже сейчас данный метод позволяет избавиться от заметных отклонений вычислений с двойной точностью от вычислений с одинарной. Дальнейшие планы На текущий момент полученная в результате работы программа уже применялась для моделирования реальных событий на примере цунами, зародившегося возле острова Самоа в сентябре 2009 года. Сравнение результатов моделирования с результатами, полученными в реальности, показало заметное сходство, но для более детального анализа потребуется произвести моделирование на более подробных сетках моделирования. Однако помимо этого существует несколько задач, решение которых может принести заметную пользу для дальнейшего развития проекта: • исследование различных параметров запуска программы позволит сбалансировать время вычислений и их точность; • дальнейшая оптимизация программы. В планах уже есть несколько допустимых оптимизаций, которые могут заметно увеличить скорость расчета; • написание удобного графического интерфейса облегчит обращение с программой для простых пользователей; • создание сетевого клиент-серверного комплекса приложений позволит использовать для моделирования вычислительные ресурсы удаленных серверов. Заключение В процессе данной работы был выполнен перенос кода программы с языка Fortran на язык C с оптимизацией под вычислительную платформу Intel. В итоге при использовании 16-ядерной системы над общей памятью SMP 4 x Intel Xeon CPU X7350, 2.93 GHz среднее время выполнения одной вычислительной итерации алгоритма сократилось в 16 раз. Однако попытка использования для вычислений системы с процессором Intel Core i7 950, несмотря на меньшее количество вычислительных ядер, показала лучшие значения скорости работы программы, производя вычисления в полтора раза быстрее. Таким образом, суммарное время расчета задачи сократилось с 8 часов до нескольких десятков минут. Литература 1.

2.

3. 4.

NOAA Center for Tsunami Research [Электронный ресурс] = Национальный центр исследования цунами: описание программного комплекса – Электрон. Дан. – Seattle, WA[2010] – Режим доступа: http://nctr.pmel.noaa.gov/model.html, свободный – Загл. с экрана. Титов В.В. Метод численного расчета цунами с учетом трансформации волны на мелководье [Текст] / В.В. Титов; акад. Наук. СССР, Сибир. Отд., Вычисл. Центр – Новосибирск: Препринт, 1988. 25 с. Стокер Дж. Дж. Волны на воде. [Текст]; М.: ИЛ, 1959. 617 с. M.Lavrentiev Jr., A.Romanenko, Speeding up of MOST program, Geophysical research abstracts, Vol. 10, EGU2008-A-00000, 2008.

ИСПОЛЬЗОВАНИЕ СИМУЛЯТОРА ВЫЧИСЛИТЕЛЬНОГО КЛАСТЕРА ДЛЯ ИССЛЕДОВАНИЯ АЛГОРИТМОВ ПЛАНИРОВАНИЯ ЗАДАЧ П.Н. Полежаев, В.П. Гергель Оренбургский государственный университет E-mail: [email protected] Проблема эффективного планирования параллельных задач, поступающих в управляющую систему вычислительного кластера, является актуальной, так как современные алгоритмы планирования не обеспечивают необходимого качества составляемых расписаний запуска задач. Довольно часто возникает ситуация, когда вычислительные узлы простаивают, хотя в очереди есть ожидающие своего исполнения параллельные программы. В связи с этим возникла необходимость исследования существующих алгоритмов планирования и разработки их новых эффективных вариантов. Для данной цели была разработана первая версия симулятора вычислительного кластера и его управляющей системы [1]. С его помощью ранее было проведено сравнительное исследование различных алгоритмов планирования, использующих списочные алгоритмы выбора, алгоритм Backfill совместно с методами назначения First Fit, Best Fit, Fastest Node Fist и Random First [1, 2]. В качестве критерия доступности узлов для планирования использовалась свертка загруженности его процессора, 176

Труды конференции Телематика’2010

оперативной и дисковой памяти. Исследование проводилось на четырех сценариях – гомогенном или гетерогенном кластере при наличии или отсутствии локальной загрузки вычислительных узлов. Рассматривались все возможные рациональные сочетания алгоритмов выбора задачи из очереди с методами ее назначения при фиксированном критерии доступности узлов. В результате было выявлено [1], что алгоритмы планирования с методом выбора Backfill по производительности работы кластера превосходят алгоритмы с Most Processors First Served Scan (MPFS Scan) во всех четырех сценариях. При гомогенном кластере разница между ними была небольшая, а при гетерогенном – существенная. Тем не менее, алгоритм Backfill по сравнению с MPFS Scan более сложен в реализации и требует указания пользователем точных оценок времени выполнения для задач. В каждом сценарии лучшие результаты в сочетании с алгоритмом выбора продемонстрировал свой метод назначения задач на узлы: гомогенный кластер без локальной загрузки узлов – Random First, гомогенный кластер с локальной загрузкой – Least Utilized Node First, гетерогенный кластер при наличии или отсутствии локальной загрузки – Fastest Node First. Однако, рассмотренные нами первоначально алгоритмы планирования, реализуемые во многих современных управляющих системах вычислительных кластеров, не учитывают особенности размещения процессов задач на узлах вычислительной системы. Это часто приводит к существенным коммуникационным задержкам, возникающим, когда значительно распределенные планировщиком по физической сети процессы параллельной задачи активно обмениваются между собой сообщениями. Данная проблема становится особенно существенной, когда между процессами нескольких одновременно выполняющихся параллельных задач возникает конкуренция за сетевые ресурсы. Также необходимо учитывать современную тенденцию использования многоядерных процессоров при построении вычислительных узлов. В связи с этим было принято решение о разработке новой версии симулятора вычислительного кластера и его управляющей системы, учитывающего явно коммуникационные задержки и многоядерные процессоры вычислительных узлов. В его основу легли представленные в настоящей статье улучшенные варианты разработанной ранее модели вычислительной системы и ее имитационной схемы, модели планировщика, модели вычислительной загрузки кластера, а также системы критериев и метрик сравнения алгоритмов планирования. 1. Имитационная схема и модель вычислительного кластера Имитационная схема управляющей системы вычислительного кластера приведена на рис. 1.

Рис. 1. Имитационная схема вычислительного кластера

177

Источник

I

управляющего узла

p0 .

Канал

S

представляет собой планировщик, который в соответствии с

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

Q

и назначение их на

P = { p1 , p2 ,K, pn } содержит все вычислительные узлы кластера, связанные узлом p0 с помощью отдельной управляющей сети. Пусть X i = {χ i ,1 , χ i ,2 , K , χ i , C }

Множество выделенным

Q

генерирует поток параллельных задач, отправляемых пользователями в очередь

i

множество вычислительных ядер узла

с –

pi . Они могут относиться как к отдельным процессорам узла (по

одному ядру на каждом), так и к нескольким многоядерным процессорам. С целью упрощения модели они

рассматриваются,

как

единое

множество

Xi .

Обозначим

n

X = Ui =1X i

–

множество

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

GT = ( P, K , E , b, c, m, d , s ),

(1)

K = {k1 , k 2 , K, k z } – множество коммутаторов, E – множество направленных сетевых связей между ними, b : E → Z + ∪ {0} – отображение, характеризующее пропускную способность каждой связи в байтах в секунду. Функции c, m, d : P → Z + определяют для каждого вычислительного узла pi где

c( pi ) = Ci , объемы оперативной m( pi ) = M i и Отображение s : P → R+ для узла pi задает

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

d ( pi ) = Di

в килобайтах.

относительную производительность

s ( pi ) = Si

каждого его вычислительного ядра, которая определяет,

во сколько раз ядра данного узла работают быстрее вычислительных ядер самого непроизводительного узла кластера. Заметим, что орграф (1) позволяет моделировать статические и динамические сети с полнодуплексными и полудуплексными связями. В рамках проводимого исследования рассматриваются только однородные вычислительные сети с полнодуплексными связями, но допускаются случаи наличия гетерогенных вычислительных узлов. Рассматриваются следующие топологии современных кластерных систем: двухуровневые толстые деревья, 2 D и 3D торы, k -арные n -кубы и звезды с коммутатором в центре. В настоящей моделе используется метод пакетной передачи данных между различными вычислительными узлами. На каждом сетевом устройстве (вычислительном узле или коммутаторе) используются очереди для хранения пакетов, ожидающих своей пересылки по сетевым связям. При этом применяются алгоритмы маршрутизации пакетов, характерные для конкретных топологий, в том числе метод кратчайших путей и алгоритм покоординатной маршрутизации. 2. Модель планировщика управляющей системы вычислительного кластера В алгоритме планирования выделяются следующие составляющие: алгоритм выбора следующей задачи из очереди и метод ее назначения на свободные и подходящие по ресурсам вычислительные ядра узлов кластера. На рис. 2 представлена обобщенная схема работы всех рассматриваемых в настоящей статье алгоритмов планирования. Алгоритм выбора в качестве параметров для своей работы получает текущее составленное расписание S и очередь Q ожидающих задач, результатом является измененное расписание и список спланированных задач U . В процессе своей работы он просматривает очередь, выбирает следующую задачу, затем составляет список окон планирования, подходящих для ее запуска, после чего передает ее вместе со списком методу назначения, который возвращает выбранное усеченное окно запуска для данной задачи. К числу алгоритмов планирования, которые будут экспериментально исследованы с помощью данного симулятора вычислительного кластера и его управляющей системы, относятся сочетания алгоритмов выбора задачи из очереди MPFS Scan и Backfill со следующими методами назначения, учитывающими топологию вычислительной системы [3–6]: • Paging, Multiple Buddy System, Adaptive None-Contiguous Allocation, Greedy Available Busy List, Minimizing Contention, Minimizing Contention Incremental, Manhattan Median, NEP (для топологий торов); • алгоритмы сортировки узлов (толстые деревья, звезды); • модифицированный вариант алгоритма Minimizing Contention (для произвольных топологий). А также со следующими методами назначения, не принимающими ее во внимание [1, 2]: First Fit, Best Fit, Fastest Node Fist, Random First. 178

Труды конференции Телематика’2010

Рис. 2. Обобщенная блок-схема работы алгоритма планирования 3. Модель вычислительной загрузки кластера Вычислительная загрузка кластера формируется потоком задач

J = ( J1 ,..., J m ) ,

помещаемых

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

Jj

характеризуется следующим набором параметров:

J j = (n j , mrj , drj , ~ t j , a j ,τ j , CPj ), где

nj

– количество необходимых вычислительных ядер,

mrj

и

dr j

– соответственно объемы

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

~ tj

задают оценку пользователя в секундах времени выполнения программы на узлах с

единичной относительной производительностью. Параметр очередь, а

τ j ∈ (0; ~t j ]

aj

определяет время поступления задачи в

– время, затрачиваемое задачей только на вычисления (без сетевых 179

коммуникаций) при условии единичной относительной производительности всех назначенных ей вычислительных узлов. Множество

CPj

задает набор коммуникационных паттернов задачи

Структура программы каждой параллельной задачи

Jj

Jj.

может быть представлена следующей

SPMD-моделью: Process u : for

{

i

qj

= 1 to

do

Communication( i, Computation( i,

j ); j );

} Коммуникационная часть каждой итерации может быть описана с помощью коммуникационного паттерна – ориентированного взвешенного графа следующего вида:

CPij = (Π j , pij ) , где

Π j = {π 1 , π 2 , K , π n j }

(2)

– множество процессов задачи,

pij : Π j × Π j → Z + ∪ {0} – функция,

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

CPj = {CP1 j , CP2 j ,..., CPq j j }

– множество всех коммуникационных паттернов задачи

Jj.

Выполнение фазы Communication( i, j ) для каждого процесса u заключается в том, что сначала происходит неблокируемая рассылка сообщений всем процессам множества (последователи процесса u в орграфе (2)), а затем выполняется succ ij (u ) = {v ∈ Π j : p ij (u , v ) > 0} блокируемый прием всех сообщений от процессов множества (предшественники вида точка-точка. Пусть

u ). Заметим, что в рамках настоящей модели рассматриваются только коммуникации

Tcomm.ij (u )

и

Tcomp.ij (u )

обозначают соответственно время выполнения коммуникационной и

u

вычислитительной фаз процессом данной задачи

Tj

pred ij (u ) = {v ∈ Π j : p ij ( v , u ) > 0}

задачи

Jj

на итерации

i,

тогда реальное время выполнения

может быть вычислено по формуле: qj

T j = max ∑(Tcomm.ij (u ) + Tcomp.ij (u )). u∈Π j i =1

Величина

Tcomm.ij (u )

вычислительных

узлах,

зависит от сетевой конкуренции и от физического расположения процессов на ее значение

может

быть

вычислено в

вычислительного кластера и его управляющей системы. Значение распределения суммарного времени вычислений

τj

процессе симуляции

Tcomp.ij (u )

работы

определяется путем

между отдельными итерациями SPMD-модели

задачи. Заметим, что в рамках данной модели мы, в силу незначительности, пренебрегаем временем, которое тратится на разбиение сообщения на пакеты и его сборку из них. Симуляция работы вычислительного кластера и его управляющей системы предполагает формирование потока задач. Все описанные выше количественные параметры генерируются на основе определенных законов распределений случайных величин, подобранных в результате анализа реальных трасс, собираемых на кластерных вычислительных системах [1, 3]. Опишем их более подробно. Требуемое количество вычислительных ядер класса [3]: последовательные задачи, остальные. Генерация значений будет последовательной ( n j

nj

nj .

Все задачи потока можно сгруппировать в три

2k -задачи (параллельные задачи с n j

равным степени числа 2) и

осуществляется следующим образом. С вероятностью

= 1 ),

q1

задача

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

двухэтапного равномерного распределения число

x , являющееся логарифмом n j . С вероятностью q2

k

оно будет округлено до целого ( 2 -задача), иначе получим параллельную задачу с произвольным числом требуемых процессоров. Используемые для симуляции значения параметров [3]: 180

q1 = 0.2 ,

Труды конференции Телематика’2010

q2 = 0.325 , a = 1 значение),

b = log 2 Χ

(наименьшее возможное значение),

c = log 2 Χ − 1.5

и

(максимальное возможное

p = 0.3 .

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

τj.

В данной работе используется подход, описанный в [3].

Логарифм вычислительного времени задачи имеет гипер-гамма распределение, параметр

n j . Используемые усредненные значения параметров распределения:

линейно зависит от

β1 = 0.823 , α 2 = 639.1 , β 2 = 0.0156 , p = -0.003n j + 0.6986 .

p которого α1 = 6.57 ,

линейная зависимость описывается с помощью формулы:

~ t j . В данной модели будет использован подход, ~ t j – равномерно распределенная величина в интервале [τ~j ; fτ~j ] , где f ∈ [1;4] –

Оценка пользователя времени выполнения задачи согласно которому

константный показатель, отражающий неточность оценок пользователей. Для исследования было принято значение f = 2 . Интервалы времени между поступлением задач в очередь

a j +1 − a j

имеют экспоненциальное

λ , величина которой подбирается так, чтобы задать конкретное L. Требования к оперативной mrj и дисковой памяти drj для каждого процесса задачи. На каждое Mi Di вычислительно ядро произвольного узла pi ∈ P приходится оперативной и дисковой памяти. Si Si Пусть Q1 < Q2 < ... < Qb – отсортированный по возрастанию список значений объемов оперативной распределение [1, 2] с интенсивностью

исследуемое значение для показателя системной загрузки

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

– аналогичный список для объемов дисковой памяти.

Qk оперативной и Wr дисковой памяти ( k = 1, b и r = 1, s ). На основе этих значений получим значения g kr – количество Ml D ≥ Qi и l ≥ W j , с помощью формулы: вычислительных ядер кластера, у которых Sl Sl

Пусть

ckr

W1 < W2 < ... < Ws

– количество вычислительных ядер в кластере, на которые приходится

k = b ∧ r = s, k = b ∧ r < s, k < b ∧ r = s, k < b ∧ r < s.

⎧cbs , ⎪c + g , ⎪ br +1 g kr = ⎨ br ⎪cks + g k +1s , ⎪⎩ckr + g kr +1 + g k +1r − g k +1r +1 , Тогда алгоритм генерации требований следующим:

j -й

задачи к оперативной и дисковой памяти узлов будет

2.

⎡Χ⎤ ⎡Χ⎤ n j < ⎢ ⎥ , то n j := ⎢ ⎥ . ⎢2⎥ ⎢2⎥ I := {} – множество пар индексов вначале пусто.

3.

Для каждого

1.

Если

такое

r

k = 1, b

найти такое наибольшее

r,

найти нельзя, то переходим к следующему

пару найденных индексов:

I := I ∪ {( k , r )} .

g kr ≥ n j . Если для данного k значению для k , иначе – сохраняем

чтобы

4.

Выбрать случайно и равновероятно упорядоченную пару индексов

5.

Выбрать произвольное значение

[mrmin ; Qk ] , где mrmin 6.

Выбрать

из

I

.

(равномерное распределение) из интервала

– минимальный объем требуемой оперативной памяти.

произвольное

[ drmin ;Wr ] , где drmin

mrj

(k , r )

значение

drj

(равномерное

распределение)

из

интервала

– минимальный объем требуемой дисковой памяти. 181

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

qj

Количество итераций

mrmin = md min = 1024

Кб.

SPMD-модели задачи имеет фиксированное значение из отрезка

[1;1000] , задаваемое непосредственно пользователем симулятора вычислительного кластера. Коммуникационный паттерн

CPij

для

i -й итерации SPMD-модели задачи. Тип коммуникационного

паттерна для всех итераций задачи задается фиксированным согласно выбору пользователя симулятора. Допустимые значения типа: • Random. Каждый процесс пересылает сообщение одному другому случайно выбранному процессу. • Pairs. Процессы случайно разбиваются на пары и обмениваются сообщениями между собой. • Ring. Процессы объединяются в кольцо. Каждый процесс посылает сообщения следующему и принимает данные от предыдущего. • One-to-all. Один случайно выбранный процесс рассылает сообщения всем остальным. • All-to-all. Каждый процесс отправляет сообщения остальным процессам. Во всех случаях для выбора случайного процесса используется равномерное распределение. Для всех дуг

(u, v) ,

существующих в

CPij ,

вес

pij (u, v)

(количество передаваемых пакетов)

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

µ = 40

[ pmin , pmax ] .

и

σ = 1,

при этом

Для симуляции приняты

pmin = 1 и pmax = 100 .

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

U ядер ,

потеря производительности кластера

CL ,

C max , среднее время ожидания задач в очереди замедление задач s огр . Метрики U ядер , CL и C max

максимальное время завершения задачи

t ож

и среднее ограниченное

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

t ож

и

s огр , которые имеют косвенный характер.

2.

Используемость оперативной и дисковой памяти. Включает метрики m и d , определяющие соответственно средние загруженности оперативной и дисковой памяти вычислительных узлов. Позволяет выявить процент неиспользованных ресурсов.

3.

Сбалансированность загрузки узлов. Определяет метрики Du , Dm и Dd , обозначающие соответственно дисперсии загруженности ядер, оперативной и дисковой памяти вычислительных узлов. Демонстрирует честность алгоритма планирования по отношению к узлам. Гарантированность обслуживания задач. Включает метрики максимального времени

4.

ожидания задач в очереди

sогр max .

tож max

и максимального ограниченного замедления задач

Данный критерий имеет особую важность в случае, если кластер используется в

рамках системы реального времени.

Dt ож

– дисперсию времени

5.

Честность по отношению к задачам. Содержит метрику

6.

ожидания задач в очереди. Позволяет оценить степень равноправности задач с точки зрения алгоритма планирования. Коммуникационный критерий. Включает следующие метрики: среднее суммарное расстояние

SD

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

задач, средняя дисперсность задач JD и среднее время блокировки сообщений MB . Данный критерий позволяет оценить сетевую конкуренцию и степень фрагментации параллельных задач. При исследовании различных алгоритмов планирования нас, прежде всего, интересует производительность составляемых ими расписаний. Поэтому при анализе алгоритмов, в первую очередь, будет рассматриваться первый критерий системы, остальные – имеют вторичный характер. 182

Труды конференции Телематика’2010

Анализ алгоритмов планирования по определенному критерию представляет собой сравнение для различных алгоритмов графиков зависимостей метрик этого критерия от величины системной загрузки L и выбор лучшего варианта для того или иного случая. Системная загрузка, определяется как отношение суммарного объема вычислительной работы всех задач к объему работы, который кластер может потенциально выполнить (при полной загруженности) за время до появления в управляющей системе последней задачи. Заключение В данной работе приведены модели вычислительной системы, планировщика и вычислительной загрузки кластера, описана имитационная схема его работы, а также сформирована система критериев и метрик сравнения алгоритмов планирования. На их основе был разработан симулятор вычислительного кластера и его управляющей системы, учитывающий его топологию и многоядерность процессоров узлов. Он будет использован для исследования существующих алгоритмов планирования и разработки их новых эффективных вариантов. Исследования выполнены при поддержке Федерального агентства по образованию в рамках реализации ФЦП «Научные и научно-педагогические кадры инновационной России» на 2009-2013 гг. (государственный контракт №П2039). Литература 1.

2. 3. 4.

5.

6.

Полежаев П.Н. Исследование алгоритмов планирования параллельных задач для кластерных вычислительных систем с помощью симулятора // Параллельные вычислительные технологии (ПАВТ’2010): Труды международной конференции. – Челябинск: ЮУрГУ, 2010. – С. 287-298. Топорков В.В. Модели распределенных вычислений. М.: ФИЗМАТЛИТ, 2004. – 320 c. Lublin U., Feitelson G. The workload on parallel supercomputers: modeling the characteristics of rigid job // Journal of Parallel and Distributed Computing archive. V. 63. № 11, 2003. – P. 542–546. Moore S.Q., Lionel M.N. The Effects of Network Contention on Processor Allocation Strategies // Proceedings of the 10th International Parallel Processing Symposium. – Washington, DC: EEE Computer Society, 1996. – P. 268-273. Bani-Mohammad S., Ould-Khaoua M., Abaneh, I. An efficient processor allocation strategy that maintains a high degree of contiguity among processors in 2D mesh connected multicomputers // Proceedings of ACS/IEEE International Conference on Computer Systems and Applications, AICCSA. – 2007. – P. 934-941. Bender M.A., Bunde D.P., Demaine E.D. Communication-Aware Processor Allocation for Supercomputers // Lecture Notes in Computer Science. V. 3608/2005. – Berlin: Springer, 2005. – P. 169-181.

СИСТЕМА МОНИТОРИНГА И УПРАВЛЕНИЯ КЛАСТЕРНЫМИ УСТАНОВКАМИ СЕМЕЙСТВА СКИФ – SkifMon М.В. Гумин, М.В. Стоцкий Учреждение Российской академии наук Институт программных систем имени А.К. Айламазяна РАН, г. Переславль-Залесский E-mail: [email protected] 1. Введение Основная тенденция в развитии высокопроизводительных вычислительных установок состоит в том, что среднее число вычислительных узлов, образующих кластер, растет [1]. С ростом числа узлов усложняется обслуживающее оборудование – источники бесперебойного питания, электропитающие установки, системы охлаждения, сетевые коммутаторы, дисковые массивы и пр. Для большой установки, включающей в себя тысячи процессоров, модулей памяти, вероятность отказа оборудования значительно возрастает по сравнению с однопроцессорным компьютером. Мы работаем над созданием системы мониторинга и управления кластерными установками семейства СКИФ – SkifMon. Система мониторинга SkifMon разрабатывается как гибкая, модульная и масштабируемая система, способная обслуживать достаточно большие установки, содержащие десятки тысяч узлов. Система мониторинга SkifMon способна наблюдать за узлами кластера и обслуживающим оборудованием, используя SNMP [2], ServNet, IPMI [3], программные агенты и др. Система мониторинга спроектирована таким образом, что позволяет легко добавлять новое оборудование для сбора статистической информации. 2. Архитектура системы мониторинга Система мониторинга и управления SKifMon для установок СКИФ включает несколько компонентов: • Сенсоры. 183

• Мон-процесс. • Архив. • Веб-интерфейс.

Рис. 1. Диаграмма системы мониторинга SkifMon 2.1. Сенсоры Сенсор в системе SkifMon – программа-драйвер источника статистической информации. Вся статистическая информация, поступающая в систему мониторинга SkifMon, проходит через сенсоры. Сенсоры работают как отдельные процессы ОС GNU/Linux, связанные с мон-процессом каналами (pipe). Сенсор может работать на одной машине с мон-процессом, или быть запущен на удаленной машине при помощи ssh. Сенсоры запускаются однократно при старте системы, и периодически посылают мон-процессу порции статической информации, называемые слайсами. Сенсор системы мониторинга может быть реализован на любом языке программирования, и получать информацию любыми средствами, например путем непосредственного считывания показаний датчика. Единственное обязательное требование к сенсору – он должен формировать слайсы установленного формата. Сенсоры могут быть «толстыми» и «тонкими». Тонкие сенсоры формируют слайсы с сырой статистикой или с частично декодированной, не производя никаких подсчетов. Толстые сенсоры производят анализ, декодируют, если требуется, и выставляют оценки, тем самым они берут на себя часть вычислений и разгружают центральный узел. Поддержка двух архитектур позволяет системе быть более динамичной, мобильной и масштабируемой. 2.2. Мон-процесс Мон-процесс является ядром системы SkifMon. Задачей мон-процесса является сбор статистической информации, поступающей от сенсоров, оценка работоспособности наблюдаемых объектов и их характеристик, архивация, выявление изменений в состоянии системы, оповещение персонала и реакция при обнаружении определенных изменений характеристик наблюдаемых объектах. В работе мон-процесса можно выделить следующие этапы: 1. Запуск сенсоров, список которых задан в конфигурационном файле. 2. Постоянный сбор поступающих от сенсоров слайсов. 3. Возможна обработка слайсов предоценочными функциями (изменение слайсов, генерация виртуальных/временных слайсов). 4. Сохранение слайсов в архиве. 5. Обработка слайсов оценочными функциями. 6. Обновление элементов вектора состояния системы. 7. По истечении заданной в конфигурационном файле длительности шага работы системы: • конструирование слайсов из виртуальных/временных слайсов; • выставление финальных оценок за период; • построение списка изменений в состоянии системы; • обработка списка изменений подсистемой оповещения; • сохранение вектора состояния системы; • перезапуск неработоспособных сенсоров. 8. Переход к пункту 2. 2.3. Архив После обработки мон-процессом слайсы поступают на хранение в архив. Реализация архива выбрана исходя из требований длительного хранения информации и масштабируемости системы. Для того чтобы архив не требовал непомерного объема дискового 184

Труды конференции Телематика’2010

пространства, используется сжатие с помощью утилит tar и bzip2. Характерной особенностью содержащейся в слайсах информации является высокая степень повторяемости фрагментов текста, в результате чего сжатие работает с высокой эффективностью. Параметры компактирования архива могут быть подобраны локальным администратором. При этом происходит выбор между увеличением коэффициента сжатия и скоростью доступа к недавно сохраненным слайсам. Параметры чистки архива могут быть настроены локальным администратором и позволяют выбрать период времени, за который система должна сохранять собранную статистическую информацию, с учетом имеющегося в распоряжении дискового пространства. 2.4. Веб-интерфейс В системе мониторинга предусмотрен веб-интерфейс, который позволяет персоналу оценить состояние наблюдаемого кластера. Интерфейс системы SkifMon доступен в режиме удаленного доступа по протоколу http (https). При проектировании веб-интерфейса была сделана попытка охватить всевозможные подсистемы кластера с целью иметь один интерфейс для наблюдения и управления кластером. Была заложена поддержка пользователей, чтобы иметь возможность для различных пользователей ограничивать доступ к данным системы мониторинга или разрешать некоторые действия над кластером, например, включение и выключение узлов. При кодировании веб-интерфейса к системе мониторинга SkifMon активно использовалась библиотека javascript функций jQuery, что позволяет легко менять внешний вид интерфейса, использовать готовые элементы интерфейса пользователя.

Рис. 2. Снимок экрана веб-интерфейса 2.4.1. Архитектура Веб-интерфейс к системе мониторинга и управлений SkifMon имеет модульную структуру. В момент загрузки web-страницы браузер посылает запрос управляющей станции, получает от нее описание разделов, которые будут отображаться в интерфейсе системы мониторинга. Для каждого раздела, который может содержать информацию о нескольких объектах мониторинга, выделяется пункт 185

в меню интерфейса, место в html-структуре документа для вывода собираемой системой мониторинга информации и запускается javascript-функция, которая следит за обновлением информации на сервере. Функции веб-интерфейса, используя технологию Ajax [4], связываются с мон-процессом системы мониторинга и получают статистические данные, которые отображают в окне браузера. Информация на странице обновляется, используя подход длинных опросов [5], другими словами, страница обновляется при поступлении в систему мониторинга новой информации, тем самым снижается нагрузка на систему мониторинга. При таком подходе разные разделы системы мониторинга являются относительно независимыми, что облегчает добавление новых разделов с данными мониторинга в интерфейс системы мониторинга. 2.4.2. Построение графиков Для каждого пользователя в интерфейсе системы мониторинга предусмотрена возможность отображения своего набора интересных пользователю графиков. Пользователи системы мониторинга могут создавать и редактировать так называемые профили графиков. Каждый профиль может содержать необходимое число графиков, отображающих историю поведения каких-либо величин. Заключение Был проведен ряд тестов с моделированной нагрузкой в 10–50 тысяч узлов, при этом нагрузка на файловую систему, процессор и память была разумной. Система мониторинга SkifMon на текущий момент не использовалась на крупных установках. Есть успешный опыт применения в мониторинге локальных сетей ООО «Ботик технологии» (более 2500 абонентов, более 300 устройств коммуникационного оборудования). Литература 1. TOP500.Org. Top500 supercomputing sites. http://www.top500.org/. 2. Bruey, D. Snmp: Simple? network management protocol. – 2005. – December. http://www.rane.com/note161.html. 3. Corporation, I. Intelligent platform management interface. http://www.intel.com/design/servers/ipmi/. 4. Wikipedia. Ajax (programming) – wikipedia, the free encyclopedia. – 2010. http://en.wikipedia.org/w/index.php? title=Ajax_(programming). 5. New Adventures in Comet: polling, l. p. o. H. s. w. A. W. o. t. c. Arcand. – 2007. http://jfarcand.wordpress.com/2007/05/15/new-adventures-in-comet-polling-long-polling-or-http-streamingwith-ajax-which-one-to-choose/.

ВЕРИФИКАЦИЯ АЛГОРИТМА ПОДДЕРЖКИ ТРАНЗАКЦИОННОЙ ПАМЯТИ А.Б. Беляев Санкт-Петербургский государственный политехнический университет E-mail: [email protected] Аннотация Широкое внедрение многоядерных процессоров в практику программирования существенно повысило важность проблемы разработки параллельных программ. Одним из подходов, позволяющих существенно упростить параллельное программирование, является технология транзакционной памяти. Доклад содержит результаты анализа одного из алгоритмов реализации транзакционной памяти для многоядерных процессоров. Этот алгоритм был предложен в работе, представленной на десятой Международной конференции PaCT’09. Работа также содержала аналитическое доказательство корректности алгоритма, в котором в дальнейшем были обнаружены пробелы. В настоящем докладе приводятся результаты автоматической верификации этого алгоритма в системе Spin, которая показала, что алгоритм не удовлетворяет критерию корректности транзакционной памяти. Найденная ошибка очень тонкая: в некоторых специальных случаях транзакция способна выполнить операции с несогласованными данными, что может привести к сбою системы. Алгоритм был исправлен. Верификация исправленной версии алгоритма ошибок не обнаружила. Введение При современном развитии многоядерных процессоров и параллельного программирования вопросы корректности программ и обнаружения в них ошибок стоят очень остро. Разработчик не может предугадать все возможные варианты поведения параллельных взаимодействующих процессов. Поэтому любая параллельная программная система должна быть подвергнута комплексу процедур тестирования и верификации. Это касается и одной из наиболее обещающих на сегодняшний день технологий, призванных упростить разработку корректных программ для многоядерных процессоров – транзакционной памяти [3]. Транзакционная память осуществляет управление доступом к разделяемой памяти при 186

Труды конференции Телематика’2010

параллельном программировании, представляя собой аппаратно или программно реализованные ограничения доступа к памяти. Благодаря этим ограничениям, выделенные в параллельных программах участки кода могут рассматриваться как транзакции, то есть логически неделимые программные единицы, результат параллельного выполнения которых эквивалентен результату некоторого их последовательного выполнения. Наличие транзакционной памяти должно гарантировать полное отсутствие логических ошибок, связанных с синхронизацией процессов при выполнении параллельных программ на многоядерных процессорах. Это освобождает разработчика от необходимости использования примитивов синхронизации, неосторожное применение которых часто приводит к новым ошибкам, а также последующих процедур тестирования и верификации готового продукта. Задача программиста сводится к тому, чтобы те участки кода, в которых происходят обращения к общей памяти, выделить как транзакции. Реализация поддержки транзакционной памяти не тривиальна. Соответствующий алгоритм работает с параллельными процессами, поэтому в нем самом могут быть ошибки. Следовательно, такой алгоритм должен быть верифицирован. В данной работе приводятся результаты исследования «оконного» алгоритма транзакционной памяти (“window-based software transactional memory system”), аналитическое формальное доказательство корректности которого было предложено на десятой Международной конференции PaCT’09 [5]. 1. Исследуемый алгоритм «Оконный» алгоритм представляет собой описание трех операций: чтения, записи и завершения. Первые две используются для обращения транзакции к переменным, последняя фиксирует результат выполнения транзакции. Основные идеи алгоритма: • Каждая транзакция читает значения переменных (адресов) из разделяемой памяти один раз, в дальнейшем обращаясь к локальным копиям этих переменных (в операции чтения). • Модификация переменных всегда осуществляется локально (в операции записи). Реальная запись происходит, когда принято решение об успешном завершении транзакции (в операции завершения). • С каждой транзакцией ассоциируется временное окно из временных меток, связанных с модификацией наблюдаемых (прочитанных или записанных транзакцией) переменных. Временные метки – значения логических часов, глобальной целочисленной переменной. Верхняя граница временного окна для транзакции T – наименьшая величина из значений логических часов перед модификацией переменных некоторыми транзакциями, отличными от T, после прочтения этих переменных транзакцией T. Нижняя граница – наибольшая временная метка модификации переменных, прочитанных T. Временные метки модификации записываются в ячейки памяти вместе с новыми значениями переменных (в операции завершения). Временные метки модификации представляют собой результат атомарной инструкции Fetch&Increment, которая увеличивает значение логических часов на единицу и возвращает их старое значение. Верхняя и нижняя границы инициализируются соответственно значениями +∞ и 0. • Транзакция принимается или отклоняется в зависимости от состояния временного окна: при конечной верхней границе отклоняются пишущие транзакции (во время операции завершения), при пустом окне – любые (во время операции чтения). Ниже приведен алгоритм из [5]:

operation X.readT(): (01) if (не создана локальная копия X) then (02)

выделить память lcx для копии;

(03)

заблокировать X; lcx ← X; RSX ← RSX U {T};

(04)

снять блокировку с X;

(05)

lrsT ← lrsT U {X}; min_ dateT ← max(min_dateT , lcx.date);

(06)

if (min_dateT > MAX_DATET) then return(abort) end if

(07) end if; (08) return (lcx.value). operation X.writeT(v): (09) read_onlyT ← false; (10) if (не создана локальная копия X) then выделить память lcx для копии end if; (11) lcx.value ← v; lwsT ←lwsT U {X}; 187

(12) return (ok). operation try_to_commitT (): (13) if (read_ onlyT ) (14)

then return(commit)

(15) else заблокировать все объекты в lrsT U lwsT; (16)

if (MAX_DATET ≠ +∞) then снять все блокировки;

(17)

return(abort) end if;

(18)

current_time ← CLOCK;

(19)

for each T’ ∈

(U

X ∈lwsT

RS X

)

do Compare&Swap(MAX_DATET’ , +∞, current_time) (20)

end for;

(21)

commit_time ← Fetch&Increment(CLOCK);

(22)

for each X ∈ lwsT do X ← (lcx.value, commit_time); RSX ← ∅ ;

(23) (24)

end for;

(25)

снять все блокировки; return(commit)

(26) end if. Алгоритм использует следующий набор управляющих переменных: • CLOCK – глобальная переменная, представляющая логические часы. Увеличивается атомарной инструкцией Fetch&Increment всякий раз, когда пишущая транзакция успешно выполняет операцию завершения try_to_commitT(). • Локальные множества lrsT и lwsT хранят идентификаторы прочитанных и записанных переменных соответственно. • Множества RSX для каждой переменной X хранят идентификаторы транзакций, читавших X со времени ее последней модификации. Инициализируются пустым множеством. • Переменные MAX_DATET для каждой транзакции Т – верхние границы временных окон. • read_onlyT – локальная булева переменная, инициализируемая значением true. Принимает значение false, если транзакция T вызывает операцию X.writeT(v). • min_dateT – нижние границы временных окон. С использованием временного окна [min_dateT, MAX_DATET] формулируются следующие условия отклонения транзакции. Любая транзакция T отклоняется, если во время операции чтения ее временное окно пусто: min_dateT > MAX_DATET. Пишущая транзакция отклоняется, если при попытке завершения истинно условие MAX_DATET ≠ +∞. 2. Критерий согласованности параллельной программы Описанный «оконный» алгоритм должен обеспечивать работу транзакционной памяти, при которой сохраняется согласованность параллельной программы. Для этого параллельные транзакции, выполняемые в соответствии с алгоритмом, должны удовлетворять критерию opacity [2], образованному двумя требованиями: • Выполнение транзакций должно быть сериализуемо, т.е. результат параллельного выполнения транзакций должен быть эквивалентен результату некоторого их последовательного выполнения. • Транзакция не должна производить никаких действий с прочитанными ею несогласованными данными. 3. Верификация алгоритма Авторами [5] было представлено аналитическое формальное доказательство корректности «оконного» алгоритма, т.е. того, что транзакции, выполняемые в соответствии с ним, удовлетворяют критерию opacity. Однако известно, что доказательства корректности таких алгоритмов осложнены большим числом случаев, порожденных интерливингом (перекрытием) параллельных взаимодействующих процессов, которые необходимо рассмотреть. Это может привести к ошибкам. 188

Труды конференции Телематика’2010

Поэтому целью данной работы было проведение автоматической верификации на основе современной технологии model checking, которая представляет собой исчерпывающую проверку всех возможных состояний и вычислений модели системы на соответствие некоторому набору формальных требований (спецификации) [1]. Для верификации был использован пакет комплексной верификации Spin [4]. Данный инструмент позволяет ответить на вопрос, удовлетворяет ли анализируемая система предъявляемым требованиям, а также в случае отрицательного ответа получить ту последовательность действий, которая иллюстрирует невыполнение требований (так называемый контрпример, позволяющий найти ошибку). Основные этапы исследования I. Построение модели Для алгоритма была построена модель на языке PROMELA [4]. Каждая транзакция в модели может находиться в одном из четырех рабочих состояний и двух заключительных (Abort и Commit) (рис. 1).

Рис. 1. Схема модели выполнения транзакции Из состояния преобразования данных транзакция может недетерминированно переходить в состояния чтения, записи или завершения, в которых выполняются алгоритмы соответствующих операций, а затем возвращаться обратно (из состояний чтения или записи) или завершать работу (в состояниях чтения или завершения) в зависимости от состояния окна. II. Построение требований к поведению транзакций Исходя из формальных требований критерия opacity [2, 5], построена спецификация этого алгоритма на языке темпоральной логики линейного времени (LTL) [1]. Для этого модель была дополнена генерацией событий, которые могут быть упорядочены во времени: BT – событие начала транзакции Т; CT, AT – принятие и отклонение соответственно; COMPT – вход транзакции T в состояние преобразования данных; rT(X)v – событие чтения значения v (возвращаемое значение) в переменную X из разделяемой памяти транзакцией T. Событие записи wT(X)v определяется аналогично. При этом записываемое значение v – идентификатор транзакции T. Событие LT представляет собой точку линеаризации – момент времени, когда может быть однозначно решено, принимать транзакцию T или отклонять [5]. Событие LT может соответствовать событию CT (принятию транзакции) либо быть связанным с критическим изменением границ временных окон транзакции Т, которое впоследствии обязательно приведет к событию AT (отклонению транзакции). Результат сериализуемого параллельного выполнения транзакций эквивалентен результату их последовательного выполнения в порядке точек линеаризации. В модели события представлены флагами, которые устанавливаются один раз для транзакции (BT, CT, AT, LT, rT(X)v, wT(X)v) или меняют свое значение в зависимости от состояния транзакции (COMPT). На основании описанных событий строилось аналитическое доказательство в [5]. Эти же средства использованы в данной работе для составления формул LTL спецификации: 1. ((<> CT) → (<> LT)) /\ ((<> AT) → (<> LT)) – «принятые и отклоненные транзакции всегда имеют точку линеаризации»; 2. (<> (ET1 /\ ¬BT2 /\ (<> BT2))) → (<> (LT1 /\ ¬LT2 /\ (<> LT2))) – «если транзакция T1 завершилась раньше транзакции T2, то точка линеаризации транзакции T1 предшествует точке линеаризации транзакции T2»; 189

3.

(<> rT2(X)1) →¬((<> ((LT1 /\¬LT3 /\ ¬LT2 /\ (<> (LT3 /\ ¬LT2 /\ (<> LT2)))))) /\ (<> wT3(X))) – «если верно, что когда-нибудь транзакция T2 прочитает из X значение, записанное транзакцией T1 (транзакция T в построенной модели записывает в память свой идентификатор – , см. определение события wT(X)v), то неверно, что [когда-нибудь транзакция T3 модифицирует X И LT1 (rT2(X)1 /\ ¬LT2 /\ (<> LT2))) → (<> (LT1 /\ ¬LT2 /\ (<> LT2))) – «если верно, что до своей точки линеаризации транзакция T2 прочитает из X значение, записанное транзакцией T1, то LT1 (LT2 /\ ¬ rT2(X)1 /\ (<> rT2(X)1))) → ¬(<> (rT2(X)1 /\ (<> COMPT2))) – «если транзакция T2 читает значение, записанное транзакцией T1, после своей точки линеаризации, то она обязательно отклоняется во время выполнения текущей операции чтения (не попадая в состояние преобразования данных из состояния чтения)» (см. рис. 1). Последняя формула соответствует требованию к транзакции не производить действий с несогласованными данными (см. п. 3, требование 2), так как точка линеаризации LT2 соответствует критическому изменению границ окна (в противном случае транзакция T2 была бы уже принята и не могла выполнять чтение). III. Верификация модели Проведена верификация модели с двумя процессами, которые обращаются к двум адресам в памяти. В результате верификации обнаружена ошибка в алгоритме, а именно, найден пример вычисления, на котором формула 5), то есть требование 2 критерия opacity (см. п. 3) не выполняется. На рис. 2 представлен соответствующий пример некорректного выполнения транзакций, управляемых рассматриваемым алгоритмом, полученный в ходе верификации в системе Spin. Здесь R и W – события физического обращения к памяти (чтения и записи соответственно), число рядом – адрес; B, С и A – события начала, успешного завершения и отклонения транзакции; comp – событие входа транзакции в состояние преобразования данных.

Рис. 2. Контрпример

190

Труды конференции Телематика’2010

На первый взгляд согласованность сохранена: транзакция 2, нарушающая требование сериализуемости, отклоняется (событие A). Однако перед этим транзакция посещает состояние преобразования данных (последнее событие comp), тем самым нарушая второе требование opacity. Покажем на примере последствия такой ошибки. Пусть рис. 2 иллюстрирует обращения к памяти и вычисления двух транзакций: transaction1:: [X + 1; Y := Y/4; X := 1] и transaction2:: [1/((X + 1) – Y)], где X и Y располагаются по адресам 1 и 0 соответственно. Пусть изначально {X = 3, Y =16}. В таблице показано соответствие событий контрпримера на рис. 2 операциям чтения из памяти, записи или последовательности вычислений рассматриваемых транзакций, а также событиям их начала и завершения. Интерпретация контрпримера

transaction1

B

Begin

R1

Read 3 from X

comp

3+1

R0

Read 16 from Y

comp

16/4

W0

Write 4 to Y

W1

Write 1 to X

C

transaction2 B

Begin

R1

Read 3 from X

comp

3+1

R0

Read 4 from Y

comp

1/(4 – 4)

A

Abort

Commit

Как видно из таблицы, перед отклонением транзакции transaction2 будет произведена операция 1/(4 – 4). Таким образом, ошибка в алгоритме, пропущенная в ходе аналитического доказательства, могла привести к серьезным программным сбоям. Последующий анализ алгоритма показал, что причина его некорректности – использование атомарной инструкции Fetch&Increment(x) внутри операции завершения, увеличивающей значение переменной x и возвращающей ее старое значение. При использовании аналогичной инструкции, возвращающей новое значение, некорректных поведений системы не обнаруживается. Заключение В ходе исследования была проведена автоматическая верификация «оконного» алгоритма поддержки транзакционной памяти, описанного в [5], в результате чего в нем была найдена ошибка. Опубликованное в [5] аналитическое формальное доказательство корректности этого алгоритма также оказалось ошибочным. Анализ контрпримера, найденного системой Spin в ходе верификации, позволил выявить причину некорректности «оконного» алгоритма и исправить его. Последующая верификация исправленного алгоритма не выявила в нем ошибок, поэтому он может быть рекомендован к реализации в многоядерных процессорах. Результаты проведенного исследования были признаны авторами «оконного» алгоритма в их новой статье [6], которая содержит исправленный алгоритм с предложенной модификацией. Данная работа иллюстрирует необходимость использования процедур автоматической формальной верификации алгоритмов транзакционной памяти наряду с аналитическим доказательством их корректности. С помощью таких процедур могут быть найдены тонкие ошибки, которые проявляются редко и только в некоторых специальных случаях, поэтому они очень трудны для анализа. Но именно этим такие ошибки и опасны: они могут проявиться в какой-либо критической программе и привести к сбою вычислений. Литература 1.

Карпов Ю.Г. Model checking. Верификация параллельных и распределенных программных систем. – СПб.: БХВ, 2009. 191

2.

3.

4. 5. 6. 7.

Guerraoui R., Kapalka M. On the Correctness of Transactional Memory // Proc. 13th ACM SIGPLAN Symposium On Principles and Practice of Parallel Programming (PPoPP’08). – 2008. – pp. 175-184. Herlihy M.P., Moss J.E.B., Transactional Memory: Architectural Support for Lock-free Data Structures. // Proc. 20th ACM Int’l Symposium on Computer Architecture (ISCA’93). – 1993. – pp. 289-300. Holzmann G. Spin Model Checker. The Primer and Reference Manual. – Addison-Wesley, 2003. – 608 p. Imbs D., Raynal M. Software Transactional Memories: An Approach for Multicore Programming // PaCT 2009. LNCS. – 2009. – Vol. 5698. – P. 26–40. Imbs D., Raynal M. Software Transactional Memories: An Approach for Multicore Programming // Springer The journal of Supercomputing. – Published online: 09 February 2010. http://www.springerlink.com/content/hr4655364l588355/.

РАЗРАБОТКА ПРОГРАММНОГО КОДА ДЛЯ РЕШЕНИЯ ТРЕХМЕРНЫХ НЕСТАЦИОНАРНЫХ ЗАДАЧ ДИНАМИКИ ВЯЗКОЙ ЖИДКОСТИ В ПОЛЯХ ОБЪЕМНЫХ СИЛ. СОПОСТАВИТЕЛЬНАЯ ОЦЕНКА ЭФФЕКТИВНОСТИ ПАРАЛЛЕЛИЗАЦИИ ДВУХ ИТЕРАЦИОННЫХ МЕТОДОВ Б.Н. Цветков Санкт-Петербургский государственный политехнический университет E-mail: [email protected] В работе представляется новая версия развиваемого на кафедре гидроаэродинамики СПбГПУ исследовательского программного кода CDF (Cartesian Domain Flows), предназначенного для решения ресурсоемких трехмерных задач динамики вязкой жидкости в областях прямоугольной геометрии на многоблочных структурированных сетках. Программный код ориентирован на использование вихреразрешающих подходов к моделированию турбулентности: метода прямого численного моделирования и метода моделирования крупных вихрей. Излагаются и сравниваются результаты исследования эффективности параллелизации вычислений с использованием двух реализованных в коде численных методов решения уравнений Навье-Стокса: метода искусственной сжимаемости и метода типа SIMPLEC. 1. Введение В настоящее время решение задач о сложных турбулентных потоках современными вихреразрешающими методами требует колоссальных затрат машинного времени. Приемлемого времени и необходимой точности вычислений можно добиться, используя параллельные вычисления на высокопроизводительных системах. При организации параллельных вычислений необходимо наиболее полно использовать все имеющиеся в распоряжении вычислителя ресурсы. Практически важным становится понятие эффективности распараллеливания задачи при расчетах тем или иным методом. В данной работе представляется новая версия программного комплекса CDF (Cartesian Domain Flows), дается сравнительная оценка эффективности распараллеливания модельных многоблочных задач динамики несжимаемой вязкой жидкости в зависимости от используемого алгоритма решения уравнений Навье-Стокса. 2. Программный комплекс CDF Программный комплекс (ПК) CDF в течение нескольких лет разрабатывается на кафедре гидроаэродинамики Санкт-Петербургского государственного политехнического университета. ПК предназначен для расчетов на компьютерах с параллельной архитектурой трехмерных течений несжимаемой жидкости в областях, геометрия которых задается набором прямоугольных блоков. Комплекс CDF в базовой версии [1] использовал неявную схему второго порядка продвижения по физическому времени и метод искусственной сжимаемости для установления по псевдовремени. Автором настоящей работы в ПК был внедрен SIMPLE-подобный алгоритм, позволяющий более эффективно моделировать внутренние течения, реализован метод моделирования крупных вихрей для описания турбулентности, а также возможность учета объемных сил. В ПК CDF используются декартовы блочно-структурированные неравномерные разнесенные (MAC) сетки, стыкуемые на межблочных границах. Дискретизация пространственных операторов для законов сохранения выполнена по методу конечных объемов со вторым порядком точности. Параллелизация осуществляется в соответствие с идеологией SPMD, с использованием библиотеки подпрограмм MPI. Декомпозиция расчётной области на блоки и назначение процессов, которые будут производить вычисления в каждом блоке, производится вручную на этапе постановки задачи. При этом главный процесс производит дополнительные вычислительные операции (сбор и рассылку вспомогательных данных, определение максимальных невязок, значений величин в точках мониторинга и т.п.), а также управляет обработкой межблочных границ. Наиболее интенсивная передача данных между параллельно работающими процессами происходит во время выполнения процедур межблочного обмена на 192

Труды конференции Телематика’2010

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

Рис. 1. Межблочная граница на разнесенной расчетной сетке (выделены конечные объемы, используемые для вычисления скалярных величин – давления, температуры) В качестве постпроцессора для визуализации результатов расчетов в ПК CDF используется программа HDVIS, разработанная в Тверском государственном техническом университете под руководством проф. В.Д. Горячева [2]. Пример визуализации турбулентного течения в плоском канале представлен на рис. 2.

Рис. 2. Пример визуализации течения в канале с помощью программы HDVIS: мгновенная картина изоповерхности модуля завихренности Внедренный в ПК CDF SIMPLE-подобный алгоритм наиболее эффективно используется для моделирования течений в длинных каналах и течений с сильными локальными неоднородностями. Данный алгоритм является разновидностью метода SIMPLEC и основан на решении во всей расчётной области эллиптического уравнения для поправки давления; реализация алгоритма аналогична выполненной в работе [3]. Для решения возникающей при дискретизации системы линейных алгебраических уравнений применяется метод сопряженных градиентов. При этом используется двухуровневая схема внутренних итераций метода: локальные итерации, которые производятся только в конкретном блоке, и глобальные итерации, затрагивающие одновременно все блоки расчётной области и задействующие процедуры межблочного обмена. Такой подход позволяет повысить эффективность параллелизации программного кода, но приводит к некоторому увеличению общего числа итераций, необходимых для достижения требуемой точности решения. 193

Для описания турбулентных течений в ПК CDF применяются вихреразрешающие подходы: метод прямого численного моделирования (Direct Numerical Simulation, DNS) и метод моделирования крупных вихрей (Large Eddy Simulation, LES), реализованный в рамках настоящей работы. Операция пространственной фильтрации в методе LES при выполнении вычислений по методу конечных объемов может быть интерпретирована как осреднение по объемам ячеек расчетной сетки. В качестве локального масштаба длины в этом случае традиционно используется кубический корень из объема ячейки. В качестве подсеточной модели в ПК CDF реализована модель с одним дифференциальным уравнением для кинетической энергии неразрешаемого движения [4]. Математическая формулировка модели выглядит следующим образом:

∂k sgs ∂t

+ ui

∂k sgs ∂xi

∂ = ∂xi

3/ 2 ⎡⎛ k sgs ν t ⎞ ∂k sgs ⎤ ⎟⎟ ⋅ ⎢⎜⎜ν + ⎥ + 2ν t S ij S ij − Cε ∂ σ x ∆ k i ⎠ ⎝ ⎣ ⎦ , 1/ 2 ν t = C k k sgs ∆

.

Постоянным модели «по умолчанию» присваиваются следующие значения:

Ck

= 0.12,

Cε = 0.7,

σ k = 1. Для уменьшения подсеточной вязкости вблизи стенок может использоваться (при выборе соответствующей опции кода) демпфирующий множитель вида [5]

(

)

⎧⎪ y + / 33 2 , y + ≤ 33 D( y ) = ⎨ ⎪⎩1, y + > 33 , +

при этом найденная величина подсеточной вязкости ν t умножается на D(

y + ).

Привлечение демпфирующих соотношений подразумевает вычисление для всех внутренних узлов расчетной сетки расстояния до ближайшей стенки. В реализованном в ПК CDF алгоритме это расстояние находится путем отчасти оптимизированной процедуры перебора расстояний от данной внутренней точки до всех узлов, расположенных на стенках. На сетках большой размерности реализованный алгоритм требует существенных временных затрат, однако поскольку рассматриваемая операция является разовой, выполняемой до проведения основных ресурсоемких расчетов, то в целом затраты на расчеты наименьшего расстояния до стенки оказываются непринципиальными. В ходе настоящей работы в ПК CDF была реализована возможность учета силы Кориолиса при расчетах течений во вращающихся областях, что потребовало модификации процедур расчета потоков через границы контрольных объемов и процедур, отвечающих за выполнение граничных условий. 3. Сопоставительная оценка эффективности параллелизации Для оценки эффективности параллелизации при расчетах с помощью ПК CDF были выбраны две постановки: задача о течении в плоской квадратной полости с движущейся крышкой и задача о течении в квадратном канале. В обеих задачах трехмерные расчетные области разбивались на блоки равной размерности (рис. 3). В случае задачи о течении в квадратной полости количество блоков составляло 64 (112 границ), а в случае задачи о течении в канале – 8 (9 границ).

Рис. 3. Геометрия расчётных областей и разбиение на блоки Параметры расчетных сеток для обеих постановок задач представлены в таблице 1. Важным параметром, в значительной мере определяющим эффективность параллелизации задачи, является 194

Труды конференции Телематика’2010

отношение количества ячеек, участвующих в межблочных обменах к общему числу ячеек расчетной сетки (данный параметр обозначен в таблице φ). Таблица 1. Параметры расчетных сеток Квадратная полость Размерность Общая одного блока размерность сетки 50x50x2 320 000 100x100x2 1 280 000 160x160x2 3 276 800

ϕ,%

Канал Общая размерность сетки 160 000 1 280 000 4 320 000

Размерность одного блока 100x40x5 200x80x10 300x120x15

14 7 4.375

ϕ,% 70 35 23.3

На каждой сетке проводилось по две серии расчетов: по методу искусственной сжимаемости (AC) и по методу SIMPLEC. Расчеты выполнялись на вычислительном кластере из 16-ти узлов, на каждом из которых установлено по два двухъядерных процессора. Время расчета задачи на одном ядре процессора принималось за единицу. Основной наблюдаемой величиной являлось ускорение вычислений, то есть отношение времени расчета на одном узле кластера к времени расчета на нескольких узлах. Замерялось только время на выполнение итераций, без учета времени, затрачиваемого на чтение/запись данных, вспомогательные вычисления и т.п. Для минимизации статистической погрешности определения времени каждый расчет проводился по 3 раза с осреднением полученных результатов. Результаты расчетов сравнивались с идеальным случаем, то есть с линейным возрастанием ускорения. Результаты расчетов по методам AC и SIMPLEC для разных расчетных сеток представлены на рис. 4 (для задачи о течении в квадратной полости) и на рис. 5 (для задачи о течении в квадратном

канале). Видно, что ускорение при малых значениях параметра ϕ в расчетах на малом числе процессоров (2–8) возрастает практически линейно, при этом эффективность параллелизации составляет более 0.95. Минимальное значение эффективности параллелизации (менее 0.5)

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

64

56

56

AC 0,32m 1,30m 3,30m IDEAL

SIMPLEC 0,32m 1,30m 3,30m

48

IDEAL 40

Ускорение, a

40

Ускорение, a

48

32

24

32

24

16

16

8

8

0 0

8

16

24

32

40

Число процессоров, N

48

56

64

0 0

8

16

24

32

40

Число процессоров, N

48

56

64

Рис. 4. Ускорение расчетов по методам AC и SIMPLEC в задаче о течении в квадратной полости (размерность расчетных сеток указана на легенде в миллионах ячеек)

195

8

8

7

AC 0,16m 1.3m 4.3m IDEAL

7

SIMPLEC 0,16m 1.3m 4.3m IDEAL

6

Ускорение, a

6

Ускорение, a

5

4

5

4

3

3

2

2

1 1

2

3

4

5

6

Число процессоров, N

7

8

1 1

2

3

4

5

6

Число процессоров, N

7

8

Рис. 5. Ускорение расчетов по методам AC и SIMPLEC в задаче о течении в квадратном канале (размерность расчетных сеток указана на легенде в миллионах ячеек) 4. Заключение В современных условиях гидродинамические расчеты требуют от вычислителя понимания того, как применяемые численные методы решения многомерных задач ведут себя в условиях параллельных вычислений. В настоящей работе выявлен ряд факторов, влияющих на эффективность распараллеливания гидродинамических задач, и даются следующие практические рекомендации: • разбиение расчетной области следует проводить таким образом, чтобы блоки получались как можно более близкой размерности; • при разбиении расчетной области на блоки следует стремиться к минимизации количества ячеек на межблочных границах; • при выборе метода решения следует учитывать не только эффективность распараллеливания самого метода, но и вычислительные особенности метода применительно к тому или иному классу задач. Литература 1.

2.

3.

4. 5. 6.

196

V. Goryachev, M. Balashov, D. Rykov, E. Smirnov, O. Rykova, S. Yakubov. Net informational and computational system for CFD researchers. Proc. of the 1st Int. Conf. "From Scientific Computing to Computational Engineering",Athens, 8-10 September, 2004, CD-ROM proceedings, 1st ICSCCE, 8 p. Балашов М.Е., Горячев В.Д., Смирнов Е.М. Визуализация результатов численного эксперимента при моделировании нестационарных течений с большим объемом данных в системе HDVIS. Научный сервис в сети Интернет: решение больших задач: Труды Всероссийской научной конференции (22–27 сентября 2008 г., г. Новороссийск). – М.: Изд-во МГУ, 2008. C. 55–59. E. Smirnov and D. Zaitsev. Computations of Internal Flows Using an Artificial-Compressibility Solver Enhanced with an Elliptic Pressure-Correction Procedure // European Congress on Computational Methods in Applied Sciences and Engineering, 24-28 July 2004, Jyvaskyla, Finland (ECCOMAS 2004). Ed: P. Neittaanmaki, T. Rossi, K. Majava, et al., CD-ROM proceedings, 13 p. Абрамов А.Г., Смирнов Е.М. Численное моделирование турбулентной конвекции воздуха в подогреваемой сбоку полости квадратного сечения // ТВТ. 2006. Т. 44. № 1. С. 90–97. Зябриков В.В., Лойцянский Л.Г. Демпфирующий фактор в теории пути смешения Прандтля. // Известия АН СССР, МЖГ. – 1987. – N5. – С. 45–53. Цветков Б.Н. Численное решение задач динамики вязкой жидкости с использованием декартовых многоблочных сеток. Диссертация на соискание ученой степени магистра, СПбГПУ, 2006.

Труды конференции Телематика’2010

ОБРАБОТКА ВИДЕОИНФОРМАЦИИ С ИСПОЛЬЗОВАНИЕМ GRIDВЫЧИСЛЕНИЙ О.Н. Долинина, А.В. Ермаков Саратовский государственный технический университет E-mail: [email protected] В настоящее время во многих областях человеческой деятельности активно используют видеоинформацию для различных целей. Цифровая видеоинформация представлена двоичными видеофайлами, содержащими один видеоотрезок, то есть последовательность видеоизображений. Видеоизображения являются статичными кадрами видеоотрезка, последовательная демонстрация которых приводит к иллюзии движения демонстрируемых объектов. Создание цифровых видеоотрезков, которые демонстрируются конечному пользователю, требует прохождения последовательности операций, где можно выделить следующие этапы: • съемка видеоизображения; • запись в хранилище данных; • монтаж видеоотрезков; • обработка видеоинформации; • кодирование видеоинформации. Наиболее узким местом в процессе формирования видеофайлов является этап обработки видеоинформации. На этом этапе происходит внесение изменений в данные видеопоследовательности с целью получения изменений в видеоизображении. Эти изменения вносятся при использовании различных фильтрующих алгоритмов, алгоритмов кодирования, наложении спецэффектов, или совмещении видеоизображений с компьютерно-генерируемыми изображениями. Часто на данном этапе требуется значительный объем вычислительных ресурсов и количество времени на обработку видеоизображения. При этом производительность, обеспечиваемая ресурсами локальных вычислительных узлов, не соответствует требованиям пользователя для задач со сложными алгоритмами, применяемых к большим объемам данных. Для существенного ускорения процесса обработки применяют параллельные или распределенные алгоритмы обработки видеоотрезков, для реализации которых сегодня используют два класса архитектур: вычислительные сети и высокопроизводительные кластеры. Однако существующие методы обработки видеоинформации в вычислительных сетях позволяют эффективно использовать не более 10-15 вычислительных узлов, а использование кластеров экономически обосновано лишь для небольшого числа наиболее сложных задач. Промежуточным между двумя описанными классами решением, в плане производительности, может быть применение групп больших вычислительных сетей. Одной из современных тенденций в развитии этого направления является использование GRID-систем [1], которые обеспечивают масштабируемый распределенный компьютинг на множестве гетерогенных ресурсов (программных средств и аппаратного обеспечения), принадлежащих множеству традиционных административных доменов, и управляемый путем эффективной распределенной координации ресурсов. GRID-система обеспечивает местонезависимый, надежный, безопасный и эффективный доступ к множеству предоставляемых служб. Такая система обеспечивает единую точку входа для запуска заданий пользователями. В GRID-системах существует много различных методов, преследующих своей целью обработку работы, наиболее эффективную с точки зрения одного из параметров, например, времени обработки пользовательской задачи, или общей загруженности системы. Однако в GRID-среде отсутствуют модели эффективной обработки видеоинформации. Таким образом, представляется актуальным разработать метод обработки видеоинформации с использованием GRID-вычислений. Выделяют три основных метода обработки видеоинформации: • Параллельная обработка внутрикадрового сжатия. • Покадровая обработка. • Распределенная обработка групп изображений (Group of Pictures – GOP). В предлагаемом методе для обработки был выбран уровень GOP [2]. Он представляет собой группу изображений, сжатых с зависимостями между кадрами внутри группы, но независящих от остальных GOP. Такая система обеспечивает ряд преимуществ: • Отсутствует необходимость в предварительном раскодировании изображения. Эта задача возлагается на конечный вычислительный узел. • GOP представляет собой сжатый блок данных позволяющий эффективнее использовать каналы связи, чем при передаче несвязанных изображений. • GOP независимы друг от друга, а следовательно, могут обрабатываться распределено, что упрощает их применение в GRID-системах. Такой метод обработки обладает рядом особенностей, которые необходимо учесть при выборе метода распределения заданий в GRID-среде: • Значительный объем данных, который может сильно различаться от задачи к задаче. • Объем вычислительной нагрузки может изменяться от нескольких миллисекунд на кадр до нескольких суток. 197

• Жесткая взаимосвязь между объемом передаваемых данных и объемом вычислительной нагрузки. Эти требования позволяют сузить выбор планировщиков заданий в GRID-среде до так называемых Data intensive планировщиков, или планировщиков для задач с большим объемом данных. Их целью является нахождение возможности для оптимального использования каналов передачи данных. Среди существующих сегодня методов можно выделить два общих подхода: кластеризация данных и их повторное использование. Недостаток кластеризации данных заключается в том, что ее нельзя осуществить в открытой GRID-среде, так как для этого необходимо создавать несколько несвязанных между собой каналов передачи данных для разных групп вычислительных узлов и хранилищ данных. Подход с повторным использованием данных предполагает, что в ходе обработки каких-либо работ может произойти такая ситуация, что необходимо будет использовать тот же набор данных, что и для одной из ранее обработанных задач. В этом случае требуется не их повторная передача, а передача недостающей части данных, или только задания. Среди существующих методов был выбран метод Storage Affinity (SA). Его выбор обусловлен хорошими результатами экспериментов, которые приведены в работе [3]. Метод SA реализован в системе OurGrid [3] и основан на методе повторного использования данных. Система OurGrid реализована на базе архитектуры обмена данными Peer-to-Peer (P2P). P2P также предоставляет ряд преимуществ, позволяющих наиболее эффективно передавать данные в широко распределенных гетерогенных средах. Для того чтобы иметь возможность определить эффективность работы предложенной системы, необходимо рассмотреть задачу с математической точки зрения. Обработка представляет собой совокупность распределенно выполняемых заданий, объединенных в одну работу. Введем определение работы и задания. Задание T представляет собой неделимый блок операций, выполняемых на одном вычислительном узле. Работа

J

представляет собой множество

заданий T, которые должны быть выполнены для получения результата одной задачи. Таким образом, работа – это:

(1) где T – это задание, TN – число заданий в работе. При этом сама работа является элементом множества всех работ , обрабатываемых системой. В случае обработки видеофайла, работа представляет собой весь видеофайл, а задания составляют видеоотрезки, кратные одному GOP. Отсюда, работа (или видеопоток) содержит JK кадров с общим объемом данных

JV. Задания представляют собой отрезок TK кадров, содержащих TV данных. – это целое число, где K – число кадров в одном GOP. Отсюда:

При этом результат

(2) Таким образом,

TN можно определить как:

(3) где

– число GOP в одном задании. Время обработки работы

обработки одного задания

J составляет

секунд, а время

секунд, причем необходимо отметить, что

(4) поскольку задания обрабатываются распределенно. Для построения модели необходимо также рассмотреть характеристики GRID-среды. GRID-среда

S представляет собой набор сайтов GS, то есть:

(5) где 198

– множество всех сайтов, N – число сайтов в GRID-среде S.

Труды конференции Телематика’2010

Каждый сайт представляет собой совокупность ресурсов, управляемых локальным планировщиком распределения заданий и менеджером управления ресурсами. Выполнение работы в GRID-среде подразумевает, что любой сайт

GS

при обработке работы

может использовать ресурсы любого

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

(6) где в составе сайта.

– множество всех вычислительных узлов,

GRID-сайт, в котором вычислительным сайтом.

каждый

J,

запуск

её

G

является

вычислительным

узлом,

называется

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

Под локальным сайтом работы

узел

GN – число вычислительных узлов

обработки

происходит

на

узле .

,

для

Сайт,

для

которого

выполняется

которого

,

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

(7) где

– это число узлов

G, для которых верно

,

– число узлов

G, для

которых верно . Также необходимо учитывать алгоритм планировщика OurGrid. Его работа осуществляется на основе метода типа очереди «первый пришедший – первый обработанный». То есть первая работа в списке отправляется на первый же доступный узел, причем в случае, если доступно P узлов одновременно, распределяться будут P задач одновременно. Вычислительные узлы G могут быть описаны различным набором характеристик, например тактовой частотой и количеством ядер вычислительного узла, размером оперативной памяти. Однако такая информация не может быть использована для однозначного сравнения между собой различных комплексов программного обеспечения. Поэтому данная система пригодна для организации вычислений только в той области, где нет необходимости в высокой эффективности, и, как следствие, в знании о ресурсах. Для предлагаемого метода, целью которого является повышение эффективности, важно иметь возможность определить время обработки и сравнить его со временем, полученным при других значениях различных параметров. В то же время, ведение централизованной информации частично противоречит основным принципам GRID-систем. Для организации расчета такой производительности предлагается метод вычисления относительной производительности в единицу времени. Введем понятие производительности. Под производительностью будем понимать число задач, выполненных вычислительным узлом в единицу времени. Для узла, отвечающего за обнаружение

GP, получив время производительность GP=1. Это

ресурсов, возможно произвести тест его производительности

, затраченное на

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

(8) где

– время, затраченное на обработку тестового задания j-ым узлом. 199

Полученные значения GP характеризуют количество заданий, выполненных j-ым узлом за то же время, что и тестовым узлом, и могут быть использованы как базовая характеристика. Такая характеристика может позволить определять скорость работы узлов относительно друг друга. Также для любого узла может быть получено время обработки им задания относительно любого другого узла, для которого это время известно

(9) где

– время обработки j-ым узлом тестового задания и его производительность

соответственно,

– время обработки искомым i-ым узлом тестового задания и его

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

(10) где

– число групп узлов,

– число узлов в i-ой группе

Для вновь добавленных в систему внешних узлов первое обработанное задание присылается из расчета GP=1, и становится тестовым. В дальнейшем производительность рассчитывается, исходя из полученного тестового значения. Кроме производительности вычислительных узлов, важной характеристикой сайта является скорость U каналов передачи данных. Таким образом, повышение эффективности можно описать как нахождение таких значений

GN, которые позволят достигнуть минимально возможного

TN

и

.

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

, обрабатываемую в локальном производительностью

,

с пропускной способностью каналов связи U. Тогда время обработки составит:

(11) где время обработки задания вычисляется как:

(12) а время передачи данных задания на узел вычисляется как:

(13)

200

Труды конференции Телематика’2010

В формулах

– это время, которое требуется для обработки такого задания тестовым узлом,

–объем данных задания. Отметим, что время передачи здесь учитывается дважды, обозначая передачу данных на обработку и обратно на тот узел, с которого они были запущены. Также, формула (11) предполагает, что время, затраченное в обоих случаях, одинаково. Для задач видеообработки такое предположение является верным в том случае, если не рассматривается обработка, приводящая к сильным изменениям видеопотока, например изменение ширины и высоты кадров видеопоследовательности. Таким образом, общее время обработки составляет:

(14) Для любой реальной системы необходимо учитывать, что время обработки задания и время передачи данных также включает некоторые задержки. Отсюда, время обработки вычисляется как:

(15) где

– это задержки, возникающие при запуске и завершении приложения по обработке.

Время обработки вычисляется как:

(16) где

– это задержки, возникающие при инициализации и закрытии каналов связи, а также

задержки, возникающие на промежуточных сетевых устройствах. Значения

в общем случае являются случайными значениями, которые нельзя

определить заранее. В случае, если

TN>1, каждый блок операций, состоящий из передачи данных и обработки, должен

быть выполнен TN раз. В этом случае время обработки работы составляет:

(17) Таким образом, время обработки данных вычисляется как:

(18) А время передачи данных соответственно:

(19) Рассмотрим ситуацию, когда производительностью

GP,

GN>1,

а

TN>=GN,

при этом все узлы обладают единой

и скорость связи между узлами равна

особенностей архитектуры P2P сетей в системе, получается данных и обработок. Отсюда получаем время обработки, равное:

GN

U.

В этом случае, с учетом

одновременно исполняемых передач

(20) Заметим, что увеличение числа вычислительных узлов, на которых производится обработка, никак не влияет на задержки при обработке, которые остаются хотя и случайной, но постоянной величиной. Аналогично для времени передачи данных: 201

(21) Здесь увеличение числа узлов приводит к разделению пропускной способности канала связи между всеми узлами, и никак не влияет на задержки при передаче данных. Учитывая особенности P2P архитектуры сетей, передача данных не может быть осуществляться строго одновременно. Инициализация каждой следующей передачи осуществляется с задержкой, которая равна сумме задержек на инициализацию связи по каналу передачи данных всех предыдущих, одновременно исполняемых заданий. Таким образом, время передачи должно составить:

(22) Для данной задачи необходимо учитывать, что параметры TV и TN связаны отношением (2), отсюда в формуле (22) можно изменить число параметров, подставив это соотношение. Таким образом:

Отсюда следует окончательный вид формулы (17):

(24) Далее отметим, что влияние на данную формулу оказывают комбинации разных типов узлов, так как с учетом одинакового времени сетевого доступа, задания распределятся по принципу:

(25) Здесь TN' – это число задач, приходящихся на каждый узел, а N – общее число групп узлов. Это единое значение, которое, на основании данных о производительности узлов, позволяет получить число задач, обработанных каждой группой узлов. Чтобы получить общее время выполнения задач, достаточно рассчитать время, затраченное любой из групп узлов, то есть:

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

(27) где

(28)

202

Труды конференции Телематика’2010

(29) – число задач, последовательно выполняемых одним узлом n-го типа. Выполнение всеми узлами своих последовательных задач позволяет за единое время Следовательно, общее время выполнения работы можно представить как:

закончить

всю

работу.

Для того чтобы определить минимальное время обработки видеоотрезка, необходимо в формуле (30) подставить такие значения GN и TN, при которых f(GN, TN) будет иметь минимальное значение. Предложенный в данной работе метод циклически подбирает значения GN и TN, начиная с областей наиболее вероятного минимального значения, до тех пор, пока найденное значение не окажется минимальным. Предложенный метод состоит из последовательности шагов: • Шаг 1. Принимаем размер одного задания равным одному GOP и получаем

TN. Принимаем

число групп узлов равным единице с производительностью тестового узла. Принимаем GN равным числу узлов, имеющихся в системе. • Шаг 2. Определяем методом дробления такое число GN, что среднее значение f(GN) следующих за ним n точек не менее числа f(GN). • Шаг 3. Заполняем полученное число узлов реально существующими в сети узлами. • Шаг 4. Определяем методом дробления минимальное

f(GN) для существующих узлов.

• Шаг 5. Определяем методом дробления минимальное f(TN). • Шаг 6. В случае, если удалось улучшить значение f(GN,TN), возвращаемся к шагу 4, иначе считаем, что достигнуто минимальное значение. Предложенный метод позволяет повысить эффективность обработки видеоинформации. Это достигается за счет подбора таких параметров работы и GRID-среды, которые позволяют затратить наименьшее время на обработку работы. Литература 1. Foster I. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. / Foster I, Kesselman C, Tuecke S. // International Journal of Supercomputing Applications, 15(3):200-222, 2001. 2. ITU-T and ISO/IEC JTC 1, “Generic coding of moving pictures and associated audio information – Part 2: Video,” ITU-T Recommendation H.262 – ISO/IEC 13818-2 (MPEG-2), Nov. 1994. 3. Cirne W. Labs of the World, Unite!!! /W. Cirne, F. Brasiliero, N. Andrade, L.B. Costa, A. Andrade, R. Novaes, M. Mowbray// Journal of Grid Computing – Volume 4, Number 3

203

Материалы школы-семинара по технологиям распределенных вычислений и компьютерного моделирования

ОБРАТНЫЕ ЗАДАЧИ ДИНАМИКИ КОРАБЛЯ ДЛЯ ВИЗУАЛИЗАЦИИ ЭКСТРЕМАЛЬНЫХ СИТУАЦИЙ В БОРТОВЫХ СИСТЕМАХ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ СУДОВОДИТЕЛЯ А.А. Безгодов, С.В. Иванов, А.В. Бухановский Санкт-Петербургский государственный университет информационных технологий, механики и оптики Тел.: (812) 337-64-92, e-mail: [email protected] Повышение эксплуатационных характеристик судов и средств освоения океана в настоящее время сопровождается созданием технических средств интеллектуальной поддержки, отличающихся чрезвычайной сложностью, расширением круга решаемых задач и диапазоном эксплуатационного использования. К таким средствам относятся бортовые интеллектуальные системы, осуществляющие поддержку судоводителей при решении задач навигации и управления в экстремальных условиях эксплуатации как в стационарных условиях (тренажерные центры), так и непосредственно на борту судна. Основная задача таких систем заключается в информативном отображении динамики судна и внешних воздействий в реальном масштабе времени, а также выработка рекомендаций судоводителю с целью предотвращения возникновения опасных ситуаций. В качестве исходной информации о динамике судна используются показания датчиков динамических характеристик судна, однако сходная информация о внешних воздействиях (в первую очередь, поля морского волнения) в принципе отсутствует. Потому задача визуализации динамики корабля в бортовой системе поддержки принятия решений в реальном режиме времени требует применения специальных методов восстановления поля морского волнения на основе данных о бортовой и килевой качке корабля. Для разработки и верификации соответствующих методов предлагается программное средство, которое состоит из двух компонент: симулятора поведения судна на нерегулярном волнении и блока анализа качки. В итоге задача визуализации морской динамической сцены разбивается на две подзадачи, в которых объектами визуализации являются поле морского волнения и трехмерный динамический объект (судно). Симулятор судна осуществляет моделирование динамики судна под воздействием морских волн. Обводы корпуса задаются в виде полигональной сетки. Параметры волнения определяются на основе стохастической модели волнового поля. В заданной вокруг судна области строится сетка, в узлах которой решается задача обтекания корпуса, т.е. вычисляются значения давления и скоростей, в результате чего определяются силы, воздействующие на корпус корабля Граничное условие на свободной поверхности задается посредством стохастической модели волнения на основе приближения Лонге-Хиггинса. Симулятор используется для определения характеристик динамики корабля при различных условиях волнообразования, что позволяет создать информационную базу для решения задачи восстановления характеристик волнения по параметрам качки. Обратная задача восстановления решается в три этапа. На первом этапе на основе соотношения Винера-Хинчина по спектрам килевой и бортовой качки восстанавливаются спектральные характеристики угла волнового склона. После этого на основе совместной модели авторегрессии–скользящего среднего, описывающей изменчивость качки и волнения, методом условных математических ожиданий восстанавливается временной ряд возвышений взволнованной поверхности в точке, соответствующей центру тяжести судна. На третьем этапе, используя полевую модель авторегрессии, восстанавливается поле волнения в окрестности судна, статистически эквивалентное (однако не обязательно идентичное) исходному возмущающему полю. Предложенный подход позволяет создавать и визуализировать различные динамические сцены, связанные с поведением морских объектов в экстремальных условиях эксплуатации, в условиях неполноты поступающей измерительной информации. Работа выполнена при частичной финансовой поддержке проектов «Высокопроизводительный программный комплекс моделирования динамики корабля в экстремальных условиях эксплуатации» и «Интеллектуальные технологии поддержки процессов исследовательского проектирования судов и технических средств освоения океана» по направлению «Судостроение», а также проектом в рамках направления «Проведение научных исследований коллективами научно-образовательных центров совместно с малыми инновационными предприятиями в области информационнотелекоммуникационных технологий» программы «Научные и научно-педагогические кадры инновационной России» на 2009–2013 годы. 204

Труды конференции Телематика’2010

СЕРВИСНО-ОРИЕНТИРОВАННАЯ РАСПРЕДЕЛЕННАЯ СРЕДА УПРАВЛЕНИЯ ПРИКЛАДНЫМИ ВЫЧИСЛИТЕЛЬНЫМИ ПАКЕТАМИ С.В. Марьин, С.В. Ковальчук Санкт-Петербургский государственный университет информационных технологий, механики и оптики Тел.: (812) 337-64-92, e-mail: [email protected] В последние два десятилетия активно развивается концепция PSE (Problem Solving Environment), определяющая облик современных программных систем для компьютерного моделирования и обработки больших объемов научных данных. PSE – это интегрированный программный комплекс, предоставляющий пользователю все необходимые для решения определенного класса задач инструментальные средства: модули, реализующие методы решения задач конкретной предметной области, инструменты выбора методов и создания композитных приложений, инструменты обработки данных и визуализации, а также инструменты добавления новых модулей и их исполнения на высокопроизводительных вычислительных платформах [1, 2]. Принципиальной особенностью PSE по сравнению с традиционными формами организации научных пакетов (препроцессор – солвер – постпроцессор) является возможность пользователю самостоятельно формировать процесс решения своей задачи из существующих расчетных модулей непосредственно в терминах предметной области. Одним из примеров реализации такого подхода применительно к задачам квантовой химии является высокопроизводительный программный комплекс HPC-NASIS [3]. Комплекс включает в себя 17 прикладных вычислительных сервисов, из которых он позволяет строить цепочку (последовательность) запусков; при этом он изолирует от пользователя реализации механизмов подготовки (форматирования) данных, выбора вычислителя, запуска задачи, и мониторинга ее исполнения. Комплекс HPC-NASIS является многоуровневой распределенной системой, позволяющей запускать вычислительные компоненты на ресурсах Грид и (или) на удаленных кластерах в рамках модели метакомпьютинга. Комплекс включает в себя уровни: взаимодействия с пользователем, управления вычислениями и пакетной обработки заданий на кластере (или запуска сервисов в Грид). Для реализации уровня управления вычислениями разработана сервисно-ориентированная распределенная среда управления вычислительными ресурсами и прикладными вычислительными пакетами. Эта среда, как подсистема комплекса HPC-NASIS, обеспечивает: • оптимальный выбор кластера или ресурса Грид для запуска; • формирование входного файла для конкретного вычислительного пакета по параметрам на основе формального описания в терминах предметной области; • предоставление сервисных «оберток» для вычислительных пакетов, их запуск; • мониторинг процесса выполнения задачи; • постобработку выходных данных, если она необходима (например, для другого пакета в последовательности, либо для сервисов постпроцессинга или визуализации). Среда управления имеет сервисно-ориентированную архитектуру (SOA) (рис. 1). Она реализована на платформе .Net; компоненты, представляющие сервисную обертку вычислительных пакетов на Linuxкластерах, работают под управлением среды Mono. В процессе подготовки заданий пользователем в HPC-NASIS среда управления получает от интерфейсной части комплекса абстрактную последовательность вычислений, то есть формальное указание на последовательность вычислительных пакетов и набор параметров, соответствующий описанию поставленной задачи в терминах предметной области. На ее основе формируется входной файл данных и скрипт запуска, выбирается кластер или ресурс Грид, исходя из предпочтений по оптимизации процесса вычислений, и запускается вычислительный пакет на исполнение. Для оптимизации выбора кластера используется набор моделей производительности (в терминах времени исполнения), которые позволяют оценивать время вычислений заданного пакета на каждом кластере с учетом параметров задачи. Разработанная среда управления может использоваться независимо от HPC-NASIS как промежуточное программное обеспечение (middleware) в других проблемно-ориентированных оболочках. Работа выполнена при частичной финансовой поддержке проектов «Инструментальная среда для построения композитных приложений моделирования сложных систем» и «Интеллектуальные технологии распределенных вычислений для моделирования сложных систем» по направлению «Технологии распределенных вычислений и систем», а также проектом в рамках направления «Проведение научных исследований коллективами научно-образовательных центров совместно с малыми инновационными предприятиями в области информационно-телекоммуникационных технологий» программы «Научные и научно-педагогические кадры инновационной России» на 2009–2013 годы.

205

Рис. 1. Высокоуровневая архитектура среды управления

Литература 1. 2.

3.

Rice J.R., Boisvert R.F. From Scientific Software Libraries to Problem-Solving Environments // IEEE Computational Science & Engineering. 1996. Vol. 3, N 3. P. 44–53. Бухановский А.В., Ковальчук С.В., Марьин С.В. Интеллектуальные высокопроизводительные программные комплексы моделирования сложных систем: концепция, архитектура и примеры реализации // Известия вузов. Приборостроение. 2009. Т. 52, № 10. С. 5–24. Васильев В.Н. и др. Высокопроизводительный программный комплекс моделирования атомно-молекулярных наноразмерных систем // Науч.-технич. вестн. СПбГУ ИТМО. Технологии высокопроизводительных вычислений и компьютерного моделирования. 2008. Вып. 54. С. 3–12.

ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ДЛЯ УПРАВЛЕНИЯ СЛОЖНЫМИ ТЕХНИЧЕСКИМИ ОБЪЕКТАМИ С.В. Иванов, Ю.И. Нечаев, А.В. Бухановский Санкт-Петербургский государственный университет информационных технологий, механики и оптики Тел.: (812) 337-64-92, e-mail: [email protected] Развитие науки, техники и технологий в настоящее время сопровождается созданием технических средств интеллектуальной поддержки, отличающихся высокой сложностью, широким кругом решаемых задач и диапазоном использования. В этих средствах (в общем случае программно-аппаратных) все чаще используются последние достижения искусственного интеллекта. Соответствующие технологии ориентированы на цепочку «моделирование – прогнозирование – принятие решений» и связаны с разработкой сложных интегрированных комплексов, включающих интеллектуальные системы различного назначения. В основе задач интеллектуальной поддержки лица, принимающего решение, заложен информационный подход, в основе которого лежит выявление и анализ аспектов, имеющих принципиальное значение для понимания сущности, тенденций и закономерностей исследуемой 206

Труды конференции Телематика’2010

ситуации. Разработка таких систем подразумевает проведение предварительного анализа рисков, для минимизации которых предназначена разрабатываемая система, анализа сценариев функционирования технического объекта под воздействием внешних условий, и определение критических параметров технического объекта. В настоящее время все большее распространение получают системы, управление которыми относится к классу слабоструктурированных, многокритериальных задач. Поэтому для решения задачи управления предлагается рассматривать СППР как интеллектуальную советующую систему, которая основывается на экспертных знаниях, результатах моделирования и интеллектуальном анализе данных. Главной отличительной особенностью предлагаемого подхода к построению архитектуры системы от традиционных способов построения информационных систем поддержки принятия решений, является: • Использование базы знаний, существующей независимо от программной реализации самой системы, что позволяет корректировать, модифицировать и дополнять ее как на этапе разработки СППР, так и в ходе эксплуатации, без ущерба остальным программным компонентам. • Наличие в составе СППР механизма логического вывода, что позволяет на основе базы знаний, описанных на формальном языке, формировать дерево решений (или цепочку рассуждений) и выполнять его обход для каждой конкретной ситуации. • Реализация адаптивной компоненты, использующей технологии физического и имитационного (статистического) моделирования в тех случаях, когда содержимого базы знаний недостаточно для генерации решения с заданной степенью достоверности – т.е. в нестандартных ситуациях. В частности, к этому относятся механизмы сравнительного анализа различных сценариев работы сложного технического объекта в экстремальных условиях эксплуатации. Результатом работы системы является набор рекомендаций, который обеспечивает минимизацию риска возникновения экстремальной ситуации при управлении техническим объектом, а также формирует возможные сценарии ее полного или частичного предотвращения. Сам по себе процесс принятия решений является задачей многокритериальной дискретной оптимизации. Для ее решения необходимо: (а) задать систему или процесс; (б) параметризовать данную систему; (в) предложить механизмы для управления системой, которые позволяют достигать требуемого субоптимального состояния в заданных ограничениях (например, за указанное время). Наиболее простой способ параметризации и описания системы – экспертный. При таком подходе эксперт описывает систему, определяет на основе эксперимента и личного опыта используемые понятия и связи между ними, определяет способ интерпретации знаний и методы решения задачи. Однако для таких сложных технических объектов применение исключительно экспертного подхода невозможно в силу отсутствия экспертов-«универсалов», способных иметь глубокие знания во всех аспектах, касающихся работы объекта. Кроме того, это связано с тем, что система является сложной и динамической; присутствует неопределенность во входных данных и интерпретации рисков. Потому для организации процесса разработки СППР принимается эволюционная модель, подразумевающая несколько «циклов качества», каждый из которых приводит к улучшению достоверности и надежности выдаваемых системой рекомендаций. Эволюционная модель разработки на первом этапе предполагает задание наиболее простой системы (модели) на основе общих знаний о работе реальной системы (только основные компоненты). После этого проводится анализ поведения системы в целом, и выделяются те ее элементы, роль которых в большей степени определяет реализацию целей управления сложным техническим объектом. Важную роль в создании таких систем играет верификация и валидация алгоритмов, реализованных в СППР, а также предварительная оценка результатов работы системы. Это должно предшествовать введению системы в опытную эксплуатацию. Реализация алгоритмов верификация, валидации и тестирования определила широкое использование всего спектра средств математического моделирования, а также достижений теории управления и инженерии программного обеспечения. Рассмотренные особенности в докладе представляются на примере интеллектуальной системы мониторинга безопасности мореплавания и системы поддержки принятия решений оператора, управляющего затворами комплекса защитных сооружений Санкт-Петербурга от наводнений. Работа выполнена при частичной финансовой поддержке проектов «Высокопроизводительный программный комплекс моделирования динамики корабля в экстремальных условиях эксплуатации» и «Интеллектуальные технологии поддержки процессов исследовательского проектирования судов и технических средств освоения океана» по направлению «Судостроение», а также проектом в рамках направления «Проведение научных исследований коллективами научно-образовательных центров совместно с малыми инновационными предприятиями в области информационнотелекоммуникационных технологий» программы «Научные и научно-педагогические кадры инновационной России» на 2009–2013 годы.

207

ОНТОЛОГИЧЕСКИЙ ПОДХОД К ПОСТРОЕНИЮ ИНТЕЛЛЕКТУАЛЬНОГО УПРАВЛЯЮЩЕГО ЯДРА СУПЕРКОМПЬЮТЕРНЫХ ПРИЛОЖЕНИЙ НОВОГО ПОКОЛЕНИЯ С.В. Ковальчук, А.В. Бухановский Санкт-Петербургский государственный университет информационных технологий, механики и оптики Тел.: (812) 337-64-92, e-mail: [email protected] Современный уровень развития суперкомпьютерных программно-аппаратных комплексов требует качественно новых подходов к построению вычислительных систем на их основе. С одной стороны, это обусловлено эволюцией высокопроизводительных вычислительных ресурсов. При этом в настоящее время наблюдается не только рост производительности доступных вычислительных систем, но и их структурное усложнение: рост популярности гетерогенных, распределенных, динамических систем. С другой стороны, сегодня во многих прикладных областях науки и техники существует обширная алгоритмическая, программная и информационная база, сформированная в ходе работ поколений исследователей. Ее использование может существенно облегчить решение множества актуальных сегодня задач, при условии интеграции существующих ресурсов. На сегодняшний день задача технической интеграции программных продуктов достаточно популярна. В первую очередь, интерес к ней проявляется со стороны разработчиков бизнес-приложений. Тем не менее, в последние годы такие концепции, как SOA (Service-Oriented Architecture) [1] и REST (Representational State Transfer) [2], находят спрос и в среде разработчиков наукоемкого ПО. Однако, обеспечивая техническую интеграцию, эти подходы требуют от разработчика реализации информационной интеграции: унификации форматов данных, процедур управления исполнением вычислительных модулей, пред- и постобработки информации. Одной из концепций, обеспечивающих информационную интеграцию существующих приложений, является концепция PSE (Problem Solving Environment) [3]. Тем не менее, обеспечивая информационную интеграцию, эта концепция требует от пользователя знаний об особенностях применения доступного ПО. Возникает необходимость в обеспечении пользователя информационной поддержкой нового уровня, предоставляющей возможность взаимодействовать с программным комплексом в терминологии избранной предметной области. Удовлетворение этой необходимости возможно в рамках концепции iPSE (Intelligent PSE) [4], оперирующей в процессе управления базой экспертных знаний. Для хранения знаний предлагается использовать онтологический подход, изначально ориентированный на детальную формализацию избранных областей знаний [5]. При этом структура онтологии условно разделяется на несколько уровней, различающихся по степени абстракции: от описания в вычислительных методов в терминах предметной области до формализации технической структуры вычислительных ресурсов. Чем выше абстрактность уровня, тем а) больше предметнозависимых классов в нем присутствует; б) меньше динамика его индивидов процессе использования системы; в) больше «неидеальность» (неопределенность, нечеткость, двусмысленность, субъективные) представленных на нем знаний. Отдельным уровнем является уровень метаописания, представляющий собой структурированные знания о процессе функционирования всей системы, многоуровневых моделях параллельной производительности и способах анализа протекающих в суперкомпьютерном приложении процессов. В целом этот уровень представляет собой инструментальное пространство для работы динамических механизмов логического вывода. Блок логического вывода в составе интеллектуальной системы ориентирован на выполнение следующих действий: а) построение набора активных фактов и операции с ним на основании системы правил; б) осуществление динамической фильтрации онтологии с последующим ранжированием допустимых вариантов решения поставленной пользователем задачи; в) обновление базы правил и онтологической структуры по результатам анализа истории использования программного комплекса. Основной задачей системы логического вывода является выбор из множества доступных вариантов запуска тех, которые обеспечивают решение поставленной пользователем задачи наилучшим образом. В процессе решения производится: а) фильтрация возможных вариантов запуска и б) ранжирование полученных вариантов в соответствии с выбранной системой критериев качества. Существенной особенностью процесса фильтрации является потенциальное несоответствие задачи, предоставляемой пользователем, тем вариантам, знания о которых заложены в составе онтологической структуры. Возможны два варианта несоответствия: субъективное (основанное на несоответствии семантической базы пользователя и системы) и объективное (проистекающее из неполноты базы знаний). При этом, устранив на основании анализа «близких» задач с привлечением дополнительных экспертных знаний указанные недостатки и решив обратную задачу вывода, можно получить расширение онтологической структуры (дообучение системы). В качестве примера на рис. 1 приведен тестовый вариант частичного онтологического описания одного из пакетов, доступных посредством высокопроизводительного программного комплекса HPCNASIS [6].

208

Труды конференции Телематика’2010

Рис. 1. Онтологическое описание одного из вариантов использования пакета ORCA в составе программного комплекса HPC-NASIS Таким образом, использование онтологического подхода для формального описания совокупности знаний предметной области требует применения специфических подходов и методов. Тем не менее, применение предложенного подхода позволяет организовать структуру базы знаний, отвечающую, с одной стороны требованиям универсальности и расширяемости (за счет использования композитной онтологической структуры), а с другой стороны, обеспечивающую унифицированный механизм работы с неопределенными, «неидеальными» знаниями. Работа выполнена при частичной финансовой поддержке проектов «Инструментальная среда для построения композитных приложений моделирования сложных систем» и «Интеллектуальные технологии распределенных вычислений для моделирования сложных систем» по направлению «Технологии распределенных вычислений и систем», а также проектом в рамках направления «Проведение научных исследований коллективами научно-образовательных центров совместно с малыми инновационными предприятиями в области информационно-телекоммуникационных технологий» программы «Научные и научно-педагогические кадры инновационной России» на 2009–2013 годы. Литература 1. 2. 3. 4.

5. 6.

B. Lublinsky. Defining SOA as an architectural style. [В Интернете] 9 January 2007 r. http://www.ibm.com/developerworks/architecture/library/ar-soastyle/. Architectural Styles and the Design of Network-based Software Architectures. R.T. Fielding. 2000. Doctoral thesis, University of California, Irvine. р. 162. Rice J.R., Boisvert R.F. From Scientific Software Libraries to Problem-Solving Environments // IEEE Computational Science & Engineering –1996. – v.3 n.3 – P. 44-53. Интеллектуальные высокопроизводительные программные комплексы моделирования сложных систем: концепция, архитектура и примеры реализации / А.В. Бухановский, С.В. Ковальчук, С.В. Марьин // Известия высших учебных заведений. Приборостроение. – 2009. – №10. – С. 5-24. T.R. Gruber A Translation Approach to Portable Ontology Specifications [В Интернете] 1993. http://tomgruber.org/writing/ontolingua-kaj-1993.pdf. Высокопроизводительный программный комплекс моделирования наноразмерных атомномолекулярных систем / В.Н. Васильев [и др.] // Научно-технический вестник СПбГУ ИТМО. Вып. 54. Технологии высокопроизводительных вычислений и компьютерного моделирования. – СПб.: СПбГУ ИТМО, 2008. – C. 3–12.

209

ПРОФЕССИОНАЛЬНАЯ КОЛЛАБОРАТИВНАЯ ИНТЕРНЕТ-СРЕДА В ОБЛАСТИ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ В НАНОТЕХНОЛОГИЯХ А.А. Гуськов, А.В. Ларченко, С.В. Ковальчук Санкт-Петербургский государственный университет информационных технологий, механики и оптики Тел.: (812) 337-64-92, e-mail: [email protected] Интернет предоставляет широкие возможности для коллаборативной активности в различных сферах человеческой деятельности. Ее отражением является появление виртуальных сообществ – групп людей со сходными интересами, которые регулярно общаются друг с другом в сети [1]. Принципиальное преимущество объединения в виртуальные сообщества – регуляризация информационного пространства (структурирование по тематике информационного контента и системы связей). Именно потому виртуальные сообщества в ряде областей являются более эффективным средством получения информации, чем традиционные тематические порталы информационной поддержки, ассоциированные с отдельными «физическими» лицами и сообществами. В целом в интернет участники виртуальных сообществ имеют общежитейский мотивационный профиль (~60%), главной тенденцией которого является направленность на общение, социальный статус и комфорт. Реже встречаются респонденты с общежитейским / профессиональным (~20%) и просто профессиональным (~10%) мотивационным профилями. При этом мотивы участия в виртуальном сообществе для этих групп принципиально различаются. Так для первого типа профиля основными мотивами являются общение по интересам, у индивидов с общежитейским / профессиональным профилем – установление и поддержание новых контактов, а у индивидов с профессиональной направленностью – доступ к информации и обмен ею [2]. В рамках данной работы рассматривается проблема формирования виртуальных сообществ с профессиональной направленностью (профессиональных сообществ). Профессиональные виртуальные сообщества можно условно разделить на два типа: с универсальной тематикой (искусство, прикладные информационные технологии и др.) и с узконаправленной тематикой (квантовая химия, молекулярное моделирование и пр.). Жизнеспособность сообщества, как самоорганизующейся системы, связана с тем, насколько легко сформировать средствами интернет активное ядро сообщества. Второй тип сообществ (с узконаправленной тематикой) обычно имеет значительно меньшее по объемам активное ядро, поэтому оно на практике часто подменяется активной «физической» группой (например, сотрудниками организации – держателя среды, в которой формируется виртуальное сообщество). К сожалению, этот способ поддержания активности в сообществе является искусственным и не может быть эффективен в течение продолжительного времени. Особенности формирования сообществ с узконаправленной тематикой связаны с тем, что в ряде случаев в них не участвуют ведущие специалисты в данной области, в силу того, что они не имеют острой нужды ни в накоплении профессионального опыта, ни в поиске партнеров через сообщество, ни в общественном признании. К их числу также относятся приверженцы традиционных методов общения. Пожалуй, основным способом мотивации таких пользователей является возможность получения новой профессиональной информации, необходимой для повседневной деятельности. Например, доступ к распределенным базам данных или использование возможностей удаленного запуска программ компьютерного моделирования. Таким образом, ключевым звеном системы становится сервис (или система сервисов), а сообщество выступает в качестве коллективного потребителя данного сервиса. С другой стороны, сообщество само является поставщиком информации и движущей силой для развития данного сервиса. Для этого лишь необходимо сделать так, чтобы вся информационная и техническая экспертная поддержка сервиса велась через данное сообщество. Примером среды, реализующей данную концепцию, является портал интеллектуальной поддержки в области квантово-механических расчетов и моделирования наноразмерных атомно-молекулярных систем и комплексов (http://hpc-nasis.ifmo.ru). В качестве образующего сервиса в данном портале использован программный комплекс HPC-NASIS, предназначенный для компьютерного моделирования и расчета наноструктур и материалов. Преимуществами такого подхода является ориентация на интерактивные средства для общения пользователей, совместное ведение проектов; единое рабочее пространство, позволяющее вести дискуссии в режиме online с использованием графических и текстовых средств общения. Кроме того, в портале предусмотрено развитие сервисов интерактивной консультации экспертов, возможность сохранения результатов выполненных задач для последующего использования другими членами сообщества или для последующего совместного обсуждения и исправления; сервисы анализа и статистики для оптимизации ведения проектов среди рабочих групп, а также для повышения эффективности расчетов с помощью комплекса (рис. 1). Литература 1. Сборник статей о создании и управлении интернет сообществом. Интернет издание, 2009. http://www.soobshestva.ru/wiki/ 2. Чураева Н.С. Социально-психологические механизмы формирования виртуальных сообществ. Автореферат на соискание уч. ст. к.п.н. Изд-во Государственного университета управления, М. – 2009. – 21 с.

210

Труды конференции Телематика’2010

Рис. 1. Схема базовых сервисов портала интеллектуальной поддержки

МЕТОДОЛОГИЧЕСКИЕ АСПЕКТЫ РЕАЛИЗАЦИИ ПОВЕДЕНИЯ НЕСТАЦИОНАРНОЙ ДИНАМИЧЕСКОЙ СИСТЕМЫ В РАМКАХ ТЕОРИИ КАТАСТРОФ Ю.И. Нечаев, О.Н. Петров Санкт-Петербургский государственный морской технический университет Тел.: (812) 369-63-37, e-mail: [email protected] Разработка интеллектуальных систем (ИС) новых поколений, функционирующих при непрерывном изменении динамики объекта и внешней среды в условиях неопределенности потребовала пересмотра методологических аспектов реализации их поведения [1–5]. В первую очередь это связано с развитием теории нестационарных систем, динамическая база знаний которых формируется на основе достижений искусственного интеллекта (ИИ). Методологической основой такой интеграции является концепция самоорганизующихся систем на базе синергетической парадигмы [4]. Анализ и интерпретация измерительной информации в бортовых ИС представляют собой одно из важных направлений формирования программной среды для реализации механизма информационной поддержки принятия решений при контроле поведения аварийного судна на волнении, как сложного динамического объекта (ДО) в различных условиях эксплуатации. Методы и модели информационной поддержки оператора при функционировании динамической базы знаний позволяют исследовать и интерпретировать с использованием современных средств моделирования и визуализации динамические процессы взаимодействия судна с внешней средой в условиях неопределенности и неполноты информации. Наибольший теоретический и практический интерес представляет разработка математических моделей, алгоритмов и программного обеспечения задач обработки данных динамических измерений и моделирования нестандартных (нештатных и экстремальных) ситуаций, связанных с функционированием бортовых ИС новых поколений. Нелинейность и нестационарность процессов взаимодействия судна с внешней средой значительно осложняют процедуры интерпретации измерительной информации в режиме реального времени [1]. Формализация знаний в сложных динамических средах нестационарной системы может быть осуществлена с использованием теории катастроф [5], позволяющей представить исходную информацию в виде топологической картины изменения характерных точек и областей исследуемых физических процессов. Анализ топологии типичных моделей катастроф [5] показал, что наиболее полное 211

описание исследуемых нестационарных процессов во время функционирования ИС может быть достигнуто с помощью катастрофы сборки. Элементами, определяющими эту катастрофу, являются: М – многообразие катастрофы: F – кривая складок; χ – отображение катастрофы; B – бифуркационное множество; С – плоскость (a,b) ; Р – точка сборки; (x,a,b) – множество точек, отображающих пространство катастроф. 2 3 Образ М задается равенством (x, – 3x , 2x ), а бифуркационное множество В есть образ в С, 2 3 задаваемый множеством точек (– 3 x , 2x ) = (a,b) Таким образом, существенные черты, связанные с отображением катaстрофы, представляются последовательностью подпространств [5]:

R2 ⊇ R1 ⊇ R0, а бифуркационное множество В отражает эту структуру и соответствующие дополнительные черты, что является универсальностью катастрофы сборки. Динамическая база знаний нестационарной системы разработана на основе принципа адаптивного резонанса [1]. Формальная нечеткая система представления знаний и механизма логического вывода обеспечивают работу системы в соответствии с гипотезой квазистационарности [1],[2]. Реализация этой гипотезы позволила осуществить перестройку топологической картины взаимодействия исследуемого ДО при взаимодействии с внешней средой в процессе эволюции системы, реализуемой в мультипроцессорной вычислительной среде [2]. В качестве объекта исследования принята динамика нелинейной самоорганизующейся системы, функционирующей в условиях неопределенности. Для этой системы, исходя из физических соображений, была разработана стратегия поведения и соответствующие сценарии. Физические картины эволюции системы на участках квазистационарности были использованы для корректировки элементов, определяющих катастрофу сборки. В результате проведенного исследования были откорректированы процедуры формирования геометрического пространства катастроф, сформулирован критериальный базис, позволяющий осуществлять контроль динамических характеристик системы на различных этапах эволюции. Таким образом, проведенное исследование позволило выяснить существенные факторы, определяющие поведение системы в нестационарной среде и разработать методологические аспекты ее практической реализации [2, 4]. Литература 1. Бортовые интеллектуальные системы. Часть 2. Корабельные системы. – М.: Радиотехника, 2009. 2. Нечаев Ю.И. Математическое моделирование в бортовых интеллектуальных системах реального времени // Труды 5-й Всероссийской конференции «Нейроинформатика-2003». М.: МИФИ. 2003. Лекции по нейроинформатике. Часть 2, С. 119–179. 3. Нечаев Ю.И., Петров О.Н. Формирование аттракторных множеств при исследовании динамики сложной системы в экстремальных ситуациях // Сборник докладов на 4-й Всероссийской научной конференции «Управление и информационные технологии УИТ-2006». Т. 2, С. 45–51. 4. Нечаев Ю.И. Нейро-нечеткая система поддержки принятия решений при оценке поведения сложного динамического объекта // Труды Х Всероссийской конференции «Нейроинформатика-2008». М.: МИФИ. 2008. Лекции по нейроинформатике. Часть 2, С. 97–164. 5. Постон Т., Стюарт И. Теория катастроф и ее приложения. – М.: Мир, 1980.

КОНТРОЛЬ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИТУАЦИЙ С ИСПОЛЬЗОВАНИЕМ ИНТЕГРИРОВАННОЙ НЕЙРОННОЙ СЕТИ Ю.И. Нечаев, И.А. Власов Санкт-Петербургский государственный морской технический университет Тел.: (812) 369-63-37, e-mail: [email protected] Обсуждаемая в настоящей работе задача связана с идентификацией трудно разделимых ситуаций в задаче мониторинга аварийного судна на волнении [1–6]. Такие ситуации были выделены на основе предварительного анализа пяти классических случаев затопления отсеков поврежденного судна на волнении [5]. Дадим краткую характеристику ситуаций, соответствующих 4 и 5 типам затопления. Четвертый тип – затопление симметричного отсека, при котором начальная остойчивость отрицательна и судно имеет крен θ1. Пятый тип – затопление асимметричного отсека. Судно плавает с креном θ1, обусловленным не только асимметричным затоплением, но и отрицательной метацентрической высотой. В отличие от предыдущего случая здесь крен на правый борт уменьшен моментом от асимметрии затопления, действующим в противоположную сторону. Проблема идентификации состоит в том, что на практике возможны ситуации, когда при равенстве углов θ1 в ситуациях 4 и 5 величина производной в точке равновесия оказывается одинаковой и разделение ситуаций, достаточно близких по физическим соображениям, становится проблематичным [5]. Попытки использования стандартных нейросетевых моделей, построенных на основе многослойного персептрона и самоорганизующейся сети Кохонена не всегда приводили к желаемому результату [1, 3]. 212

Труды конференции Телематика’2010

Физические картины поведения аварийного судна на волнении для рассматриваемых типов затопления были сформированы с использованием элементов теории катастроф для стандартной катастрофы сборки [4]. Области изменения исследуемых параметров представлялись на плоскости YZ и характеризовали исходное положение метацентра, метацентрической эволюты (многообразие катастроф), исходное положение центра тяжести (ЦТ) и центра величины (ЦВ) системы, поперечную метацентрическую высоту, кренящий момент и угол, определяющий положение равновесия. В силу симметрии судна относительно диаметральной плоскости кривая ЦВ всегда будет иметь локальный минимум либо локальный максимум, а кривая метацентров – особенность, в данном случае особенность стандартной или двойственной сборки. Таким образом, геометрическая интерпретация исследуемых аварийных ситуаций позволила сформулировать исходный информационный базис для проведения структурного и параметрического синтеза интегрированной нейронной сети. В качестве компонент интеграции использованы: сети, многослойный персептрон и самоорганизующаяся сеть Кохонена [1, 3]. Обучение интегрированной сети осуществлялось на базе специально разработанного алгоритма, который отработан в процессе специальных экспериментальных исследований. Помимо этого, в процессе эксперимента каждая из компонент интегрированной сети обучалась самостоятельно на основе алгоритма обратного распространения. Поток информации, подаваемый на интегрированную нейронную сеть, был сформирован в процессе математического моделирования динамики аварийного судна на основе расширенной модели, описываемой дифференциальным уравнением Матье [6]. В процессе обучения сети использовались различные стратегии, позволяющие отработать эффективный алгоритм обучения. Выборочные данные результатов идентификации представлены в табличной форме (табл. 1 и 2): Таблица 1. Ошибка обучения интегрированной ИНС Итерация 1 2 3

Общая ошибка обучения 0,004 0,005 0,009

Ошибка на тестовом множестве 0,21 0,17 0,03

Ошибка на подтверждающем множестве 0,27 0,11 0,03

Сравнительные данные, полученные при реализации принципа конкуренции при идентификации экстремальной ситуации 5, представлены в табл. 2. Анализ выполнен для конкурирующих вычислительных технологий, основанных на использовании стандартного алгоритма, когнитивной парадигмы (когнитивная спираль и текстуры данных) и интегрированной ИНС. Множества элементов указанных моделей определяют концепцию системы знаний формальной модели, основанной на интеграции генетического алгоритма (ГА) и мультиагентной системы (МАС) и представляющей собой множества объектов, действий и ситуаций. Таблица 2. Ошибка распознавания экстремальной ситуации (%) Номер эксперимента 1 2 3

Стандартный алгоритм 18 16 15

Когнитивная спираль 12 9,7 11

Интегрированная ИНС 5,7 4,5 5,2

Из таблицы видно, что разработанная нейронная сеть обеспечивает достаточно надежную идентификацию аварийной исследуемых ситуаций при функционировании бортовой интеллектуальной системы. Контроль ситуации и прогноз ее развития осуществлялись на основе динамической базы знаний. Нечеткие модели знаний и механизма логического вывода реализованы с использование принципа адаптивного резонанса. Литература 1. Бортовые интеллектуальные системы. Часть 2. Корабельные системы. – М.: Радиотехника, 2009. 2. Нечаев Ю.И. Моделирование остойчивости на волнении: современные тенденции. – Л.: Судостроение, 1989. 3. Нечаев Ю.И. Математическое моделирование в бортовых интеллектуальных системах реального времени // Труды 5-й Всероссийской конференции «Нейроинформатика-2003». М.: МИФИ. 2003. Лекции по нейроинформатике. Часть 2, С. 119–179. 4. Постон Т., Стюарт И. Теория катастроф и ее приложения. – М.: Мир, 1980. 5 Справочник по теории корабля. – Л.: Судостроение, 1986. 6. Хаяси Т. Нелинейные колебания в физических системах. – М.: Мир, 1979.

213

Индекс фамилий всех авторов статей А Алексеева Марина Михайловна.................................. 62 Андреев Никита Евгеньевич...................................... 164 Андрейко Дмитрий Владимирович.............................. 67 Афанасьев Константин Евгеньевич .......................... 167

Б Бегишев Антон Анатольевич ....................................... 76 Безгодов Алексей Алексеевич .................................. 204 Безматерных Геннадий Дмитриевич .................. 20, 125 Беляев Алексей Борисович ....................................... 186 Белякова Юлия Вячеславовна .................................. 139 Бордычевская Александра Сергеевна ..................... 103 Боченина Клавдия Олеговна ..................................... 153 Бубарева Олеся Александровна................................. 72 Бухановский Александр Валерьевич ........ 204, 206, 208 Быкова Мария Андреевна.......................................... 103

В–Г Власенко Андрей Юрьевич........................................ 167 Власов Илья Александрович ..................................... 212 Власова Алла Геннадьевна....................................... 135 Гергель Виктор Павлович .......................................... 176 Гудов Александр Михайлович ..................................... 92 Гумин Михаил Владимирович ................................... 183 Гуськов Александр Александрович........................... 210

Д Дашкова Екатерина Алексеевна ................................. 62 Дергачев Юрий Аркадьевич ........................................ 13 Долинина Ольга Николаевна..................................... 197 Домнин Александр Львович......................................... 29 Дружинин Михаил Михайлович ................................... 42

Е–Ж–З Еремин Михаил Анатольевич.................................... 159 Ермаков Александр Вадимович ................................ 197 Журавлёва Мария Павловна ......................................... 9 Зайков Александр Федорович ................................... 173

И

Медведева Ольга Николаевна .................................. 153 Михалкович Станислав Станиславович ................... 139

Н–О Насадкина Ольга Юрьевна........................................ 135 Нейфельд Александр Иванович ................................. 67 Нечаев Юрий Иванович ............................. 206, 211, 212 Окулов Николай Николаевич....................................... 99

П Павлов Андрей Александрович................................. 153 Первицкий Александр Константинович ...................... 56 Петров Олег Николаевич ........................................... 211 Петунин Ярослав Юрьевич........................................ 115 Писарев Андрей Владимирович.................................. 80 Подольский Владимир Ефимович....................... 42, 149 Полежаев Петр Николаевич ...................................... 176 Полукаров Данил Юрьевич.......................................... 46 Попович Юрий Львович ............................................. 131 Пушкарев Владимир Анатольевич.............................. 29 Пфайф Елена Дмитриевна .......................................... 92

Р Радченко Игорь Михайлович ..................................... 149 Рябченко Максим Евгеньевич ................................... 131

С Савельев Александр Юрьевич.................................. 149 Савин Иван Ильич ...................................................... 111 Савченко Андрей Павлович....................................... 103 Сагатов Евгений Собирович........................................ 51 Семенов Антон Александрович................................... 51 Силенин Антон Сергеевич ......................................... 120 Скляров Андрей Анатольевич ..................................... 38 Скляров Сергей Анатольевич ..................................... 38 Соловьева Анна Валерьевна .................................... 123 Соловьева Юлия Александровна ............................. 123 Стоцкий Максим Викторович ..................................... 183 Султанов Тимур Геннадьевич ..................................... 46 Сухов Андрей Михайлович .............................. 46, 51, 56

Т

Иванов Сергей Владимирович .......................... 204, 206 Игнатьев Иван Сергеевич .......................................... 106 Ильичева Светлана Вячеславовна........................... 145 Ипатова Виктория Алексеевна .................................. 115

К Казаков Владислав Витальевич .................................. 20 Камынин Алексей Валерьевич .................................. 142 Кандрин Евгений Александрович................................ 67 Карапетян Гор Арменович ........................................... 35 Кизилов Евгений Александрович ................................ 29 Ковальчук Сергей Валерьевич .................. 205, 208, 210 Котов Вадим Викторович ............................................. 84 Кохо Михаил Алексеевич ............................................. 87 Красильников Владимир Евгеньевич........................ 149 Кузнецов Артем Александрович.................................. 67 Кузнецова Наталья Юрьевна ...................................... 56

Л–М Ларченко Алексей Викторович .................................. 210 Макеев Владимир Геннадьевич .................................. 84 Марьин Сергей Владимирович.................................. 205 Маслов Владимир Алексеевич.................................... 24

Таравкова Татьяна Викторовна................................. 153 Тихонов Роман Вячеславович..................................... 84 Толстых Сергей Степанович ....................................... 42

У–Ф Устенкова Татьяна Николаевна .................................. 51 Федоров Дмитрий Олегович ...................................... 115 Финогеев Алексей Германович ................................... 24 Финогеев Антон Алексеевич........................................ 24

Х Хенкин Максим Александрович................................... 15 Хенкина Анна Артуровна ............................................. 87 Ходяков Олег Геннадьевич.......................................... 84 Хоперсков Александр Валентинович.................. 80, 159 Хоперсков Сергей Александрович ............................ 159 Храпов Сергей Сергеевич ........................................... 80

Ц–Ч–Ш Цветков Борис Николаевич ....................................... 192 Чалый Дмитрий Юрьевич ............................................ 62 Шиманский Дмитрий Николаевич.............................. 125

--------------------------------------------------------------------------------------------------------------------------------Тиражирование и брошюровка «Университетские телекоммуникации». Тел.: (812) 233-46-69. Тираж 100 экз. Зак. № 125 от 15.06.10 г. ISBN 978-5-7577-0355-8

214