Маршрут полета БЛА. 
Характеристики и визуализация

ОАО «КБ «ЛУЧ» занимается разработкой и производством сложной высокотехнологичной продукции. Одним из основных направлений деятельности ОАО «КБ «ЛУЧ» является разработка и производство комплексов с беспилотными летательными аппаратами.

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

Управление БЛА осуществляется с наземного пункта управления. При выполнении поставленных задач БЛА осуществляет полет по ранее сформированной траектории — маршруту. Возможна оперативная коррекция маршрута во время полета.

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

Задачей данной работы является разработка программного продукта (подсистемы), осуществляющего создание, редактирование и визуализацию совокупности маршрутов БЛА в нескольких окнах отображения ЦКМ одновременно. Подсистема должна являться кроссплатформенной и обеспечивать управление маршрутами согласно правилам, разработанным специалистами ОАО «КБ «ЛУЧ».

1. Анализ предметной области

При проектировании подсистемы визуализации маршрута осуществлен анализ ранее разработанного в ОАО «КБ «ЛУЧ» аналога, отмечены его ограничения, недостатки. Проанализированы требования, сформулированные компетентными в данной области сотрудниками предприятия. Изучены технические характеристики целевого оборудования, на котором планируется работа подсистемы.

Основными требованиями к подсистеме визуализации являются:

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

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

— одновременная визуализация нескольких маршрутов на ЦКМ;

— визуализация совокупности маршрутов в нескольких экранных окнах одновременно;

— корректирование маршрута с помощью мыши;

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

Ключевым документом, регламентирующим организацию, структуру, требования к разработке маршрута полета БЛА является документ «Маршрут полета БЛА из состава КВР. Организация, структура, требования к разработке». При анализе данного документа, были сделаны шаги в направлении проектирования удобного, интуитивно понятного пользовательского интерфейса диалоговых окон, упрощающих создание или изменение ранее созданной совокупности маршрутов полетов БЛА.

1.1 Постановка задачи

После анализа предметной области, изучения соответствующих документов, работы с существующим на данный момент аналогом, общения со специалистами ОАО «КБ «ЛУЧ», были конкретизированы требования к разрабатываемому программному продукту.

Требуется разработать подсистему, представляющую собой совокупность протестированных и отлаженных модулей, написанных на языке С++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4.

Подсистема должна предоставлять:

а) базовый набор графических примитивов для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик совокупности маршрутов на ЦКМ;

в) диалоговые окна для визуального создания и редактирования маршрута полета БЛА на ЦКМ.

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

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

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

а) ХТТ — характерная точка траектории, образующая точка маршрута, при прохождении которой осуществляется изменение траектории БЛА (на ЦКМ примитив отображается как круг определенного радиуса, граница которого нарисована пером заданного цвета и толщины, а внутренняя область закрашена кистью указанного цвета);

б) линия, связывающая ХТТ (условная линия, соединяющая две ХТТ, вдоль которой происходит движение БЛА при прохождении маршрута. На ЦКМ примитив отображается в виде линии, нарисованной пером заданного цвета и толщины);

в) БЛА (примитив, визуализирующий летательный аппарат. На ЦКМ примитив отображается в виде многоугольника, с заданной геометрией и количеством вершин. Границы данного примитива рисуются пером определенного цвета и толщины, а внутренняя область закрашивается кистью указанного цвета);

г) прямоугольник (базовый примитив для размещения дополнительной информации о маршруте; способ рисования аналогичен способу рисования графических примитивов ХТТ и БЛА).

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

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

1.2 Обзор аналогов

Разрабатываемый программный продукт не является самостоятельным. Аналогичные продукты представляется возможным найти в секретных (оборонных) программных системах других стран (более сорока стран мира — в том числе США, Франция, Канада, Германия, Израиль, Индия, Италия, Китай, Великобритания, Чехия, Австрия, Бельгия и др. [3, 4]) или в проектах других фирм и предприятий России (более десятка организаций — в том числе «Вега», ОАК «Вертолеты России», «Кулон», «Луч», РСК «МиГ», АХК «Сухой», ОАО «Туполев», «Камов», «Миль», «Иркут», «Топаз», «Сокол», НИИ ТП и др. [3]), но обеспечить уровень открытости архитектуры родственных подсистем для сравнения с разработанной вряд ли удастся. На основании вышесказанного, в данном разделе рассмотрен аналог подсистемы, ранее разработанный в ОАО «КБ «ЛУЧ», архитектура которого известна и, следовательно, достаточно легко выявить его ограничения, тонкие места и недостатки:

1) отсутствие специальных маневров;

2) ориентированность на визуализацию одного маршрута;

3) использование примитивного алгоритма визуализации;

4) визуализация маршрута в одном экранном окне отображения ЦКМ;

5) отсутствие редактирования маршрута с помощью мышью.

Разработанная подсистема по сравнению с ранее существующей имеет следующие преимущества:

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

2) поддерживается визуализация и редактирование совокупности маршрутов;

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

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

5) поддерживается редактирование маршрутов путем перемещения мышью их составных элементов;

6) используется гибкий и быстрый алгоритм визуализации маршрутов, позволяющий визуально выделить интересующие маршруты, отдельные маневры в маршрутах, как совокупность связанных ХТТ, так и отдельные ХТТ при редактировании маршрутов мышью.

2. Проектная документация

2.1 Техническое задание

2.1.1 Введение

Наименование темы разработки — Подсистема создания, редактирования и визуализации маршрута беспилотного летательного аппарата на цифровой карте местности.

Документ, на основании которого ведется разработка — Приказ № 109−04.

Организация, утвердившая этот документ, и дата его утверждения — Рыбинская государственная авиационная технологическая академия имени П. А. Соловьёва, 31 марта 2009 г.

2.1.2 Назначение разработки

Подсистема должна функционировать в составе специального программного обеспечения (СПО) «Проходчик», обеспечивая создание, редактирование и визуализацию совокупности маршрутов полетов БЛА одновременно в нескольких экранных окнах отображения ЦКМ формата географической информационной системы (ГИС) «Интеграция».

2.1.3 Требования к системе

2.1.3.1 Требования к функциональным характеристикам

Подсистема должна предоставлять:

а) базовый набор графических примитивов (элементов) для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик совокупности маршрутов на ЦКМ;

в) диалоговые окна для создания и редактирования маршрута полета БЛА на ЦКМ (окна управления маршрутами, маневрами и образующими точками маршрута). Подсистема также должна предоставлять диалоговые окна управления следующими специальными маневрами: «Отрезок», «Замкнутая траектория», «Круг», «Бабочка», «Восьмерка», «Змейка», «Область».

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

Организация, структура, требования к разработке маршрута полета БЛА, перечень специальных маневров и их характеристики описаны в документе «Маршрут полета БЛА из состава КВР. Организация, структура, требования к разработке».

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

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

а) характеристическая точка траектории (ХТТ — образующая точка маршрута, заданная координатами и содержащая некоторую дополнительную информацию);

б) линия, связывающая ХТТ (условная линия, соединяющая две ХТТ, вдоль которой происходит движение БЛА при прохождении маршрута);

в) БЛА (примитив, визуализирующий летательный аппарат);

г) прямоугольник (базовый примитив для размещения дополнительной информации о маршруте).

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

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

Подсистема должна обеспечивать скорость достаточную для обеспечения визуализации маршрутов на ЦКМ в реальном масштабе времени при использовании мониторов с разрешением 1280×1024 точек.

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

Подсистема должна представлять собой совокупность протестированных и отлаженных, готовых для встраивания в СПО «Проходчик» модулей, написанных на языке С++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4.

2.1.3.2 Требования к надежности

Работа программных модулей должна быть протестирована под управлением ОС: МСВС 3.0, Microsoft Windows XP.

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

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

а) интегрированной среды разработки Microsoft Visual C++ 6.0 на третьем уровне проверки;

б) ОС МСВС 3.0.

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

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

2.1.3.3 Требования к составу и параметрам технических средств

Подсистема должна функционировать в составе СПО «Проходчик». Требования к составу и параметрам технических средств определяются требованиями СПО «Проходчик».

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

В качестве управляющих ЭВМ должны использоваться ЭВМ платформы «Эльбрус-90 микро», разработанные в рамках программы «Интеграция-СВТ».

Для тестирования работы подсистемы под управлением Microsoft Windows XP могут быть использованы ЭВМ со следующими техническими характеристиками (рекомендуемыми):

— процессор: Intel Celeron, Intel Pentium III (600 МГц и выше),

— ОЗУ: 256 Мбайт и выше,

— жесткий диск: 2 Гб и выше.

В качестве устройства отображения информации должны использоваться мониторы с разрешением 1280×1024 точек.

2.1.3.4 Требования к информационной и программной совместимости

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

ОС ЭВМ, ПО общего назначения, инструментальные средства программирования должны выбираться из числа унифицированных программных средств, разрабатываемых по программе «Интеграция-СВТ».

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

При разработке ПО должны быть использованы кроссплатформенные библиотеки высокого уровня (Qt 3.3.4).

Подсистема визуализации маршрута полета БЛА на ЦКМ должна функционировать под управлением ОС: МСВС, Microsoft Windows.

Для функционирования подсистемы необходимо наличие библиотек, предоставляющих доступ к интерфейсу прикладного программирования ГИС «Интеграция»; библиотек Qt 3.3.4.

2.1.4 Требования к документации на дипломный проект

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

1. Анализ предметной области

1.1. Постановка задачи

1.2. Обзор аналогов

2. Проектная документация

2.1. Техническое задание

2.2. Пояснительная записка

2.3. Описание программы

2.4. Программа и методика испытаний

3. Эксплуатационная документация (Руководство оператора либо Руководство системного программиста)

4. Акт испытаний программного продукта

5. Экономическая часть

6. Материалы по охране труда Заключение Список литературы Приложения

2.2 Пояснительная записка

2.2.1 Введение

Наименование темы разработки — Подсистема создания, редактирования и визуализации маршрута БЛА на ЦКМ.

Документ, на основании которого ведется разработка — Приказ № 109−04.

Организация, утвердившая этот документ, и дата его утверждения — Рыбинская государственная авиационная технологическая академия имени П. А. Соловьёва, 31 марта 2009 г.

2.2.2 Назначение и область применения

Подсистема должна обеспечивать создание, редактирование и визуализацию маршрута полета БЛА на ЦКМ.

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

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

Под визуализацией понимается отображение маршрута полета БЛА на ЦКМ формата ГИС «Интеграция». Подсистема должна производить визуализацию совокупности маршрутов в нескольких экранных окнах отображения ЦКМ одновременно.

Подсистема должна функционировать в составе СПО «Проходчик», обеспечивая создание, редактирование и визуализацию совокупности маршрутов полетов БЛА одновременно в нескольких окнах отображения ЦКМ формата ГИС «Интеграция».

2.2.3 Технические характеристики

2.2.3.1 Постановка задачи на разработку программы

Требуется разработать подсистему, представляющую собой совокупность протестированных и отлаженных модулей, написанных на языке С++ с использованием кроссплатформенной объектно ориентированной библиотеки Qt 3.3.4.

Подсистема должна предоставлять:

а) базовый набор графических примитивов (элементов) для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик маршрута или совокупности маршрутов на ЦКМ;

в) диалоговые окна для визуального создания и редактирования маршрута полета БЛА на ЦКМ (окна управления маршрутами, маневрами и ХТТ). Подсистема также должна предоставлять диалоговые окна управления следующими специальными маневрами: «Отрезок», «Замкнутая траектория», «Круг», «Бабочка», «Восьмерка», «Змейка», «Область».

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

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

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

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

б) линия, связывающая ХТТ (условная линия, соединяющая две ХТТ, вдоль которой происходит движение БЛА при прохождении маршрута. На карте примитив отображается в виде линии, нарисованной пером заданного цвета и толщины);

в) БЛА (примитив, визуализирующий летательный аппарат. На карте примитив отображается в виде многоугольника, с заданной геометрией и количеством вершин. Границы данного примитива рисуются пером определенного цвета и толщины, а внутренняя область закрашивается кистью указанного цвета);

г) прямоугольник (базовый примитив для размещения дополнительной информации о маршруте; способ рисования аналогичен способу рисования графических примитивов ХТТ и БЛА).

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

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

2.2.3.2 Описание функционирования системы

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

а) создать новый маршрут;

б) выбрать маршрут для редактирования из списка имеющихся маршрутов.

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

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

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

Перечень специальных маневров и их назначение описано в Таблице 2.1

Таблица 2.1. Перечень специальных маневров

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

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

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

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

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

Кэш карты представляет собой видимый в определенном окне участок карты, расширенный до размеров равных разрешению экрану монитора ЭВМ, на котором осуществляется визуализация. Такой подход позволяет обойти достаточно «дорогую» процедуру повторной инициализации кэша при изменении его размера.

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

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

Создание и редактирование маршрута осуществляется по правилам, изложенным в документе.

2.2.3.3 Описание метода организации входных и выходных данных

При создании маршрута полета БЛА в подсистему поступает информация из диалоговых окон, на основе которой происходит создание экземпляра класса, реализующего маршрут, а также создание экземпляров классов, реализующих маневры и ХТТ по мере их добавления в состав создаваемого маршрута. Входные данные: информация из диалоговых окон. Выходные данные: экземпляр класса, реализующего маршрут, графическое представление маршрута на ЦКМ.

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

Все изменения, вносимые в маршрут полета БЛА при его создании и редактировании, фиксируются в объекте — экземпляре класса, реализующего маршрут, и отображаются на ЦКМ.

2.2.3.3.1 Схема визуализации маршрута

Подсистема визуализации маршрута полета БЛА на ЦКМ реализована на основе классической схемы MVC (Modеl/Viеw/Controllеr — Модель/Вид/Контроллер), которая позволяет обеспечить логичное и непротиворечивое разделение функциональности по классам модели, прозрачность и гибкость в реализации алгоритма визуализации.

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

Схему MVC в спроектированной подсистеме образуют три основные класса:

1) модель (сцена) — класс-контейнер, хранящий список графических примитивов — элементов, из которых складывается графический образ маршрута полета БЛА на ЦКМ и список представлений, в экранных окнах которых осуществляется визуализация;

2) вид — окно визуализации ЦКМ и маршрута полета БЛА. Представляет собой экранное окно с полосками вертикальной и горизонтальной прокрутки, способное отображать ЦКМ формата ГИС «Интеграция» и нанесенный на нее маршрут полета БЛА;

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

2.2.3.3.2 Описание классов

Основными классами подсистемы являются классы, реализующие:

1) маршрут полета БЛА (CRoutе);

2) маневр (CManеuvеr);

3) ХТТ (CTrackPoint);

4) отрисовщик маршрута (QRoutеPaintеr);

5) окно визуализации карты (QMapScrollViеw);

6) представление (QMapPaintViеw);

7) сцену (QMapPaintScеnе);

8) графические примитивы для визуализации маршрута.

Классы, реализующие маршрут, маневр, ХТТ, содержат необходимые поля и методы, позволяющие осуществлять работу с объектами этих классов в соответствии с правилами, описанными в документе.

Класс, реализующий отрисовщик маршрута, позволяет сформировать на ЦКМ графическое представление объектов класса, реализующего маршрут.

Объект класса, реализующего окно визуализации карты, представляет собой экранную область с полосами прокрутки, которая служит для отображения ЦКМ формата ГИС «Интеграция».

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

Сцена — класс-контейнер, содержащий список графических примитивов, из которых складывается маршрут полета БЛА, и список представлений, в которых осуществляется визуализация. Визуализация маршрутов в нескольких окнах одновременно реализуется путем создания объекта класса, реализующего представление, для каждого окна отображения ЦКМ. После этого каждое из представлений закрепляется за сценой, управляющей отрисовываемой последовательностью графических примитивов, образующих совокупность маршрутов БЛА.

Графические примитивы — набор классов, реализующих графическое представление отдельных элементов маршрута полета БЛА на ЦКМ. Совокупность графических примитивов для визуализации маршрута полета БЛА представляют следующие классы:

1) QMapPaintItеm — абстрактный базовый класс для всех графических примитивов;

2) QMapPaintVеctImagеItеm — класс, реализующий графический образ БЛА;

3) QMapPaintTwoDimеnsionalItеm — абстрактный базовый класс для графических примитивов, которые могут быть заданы положением на карте и двумя размерами (шириной и высотой). Примерами таких примитивов могут служить эллипс, прямоугольник, параллелограмм и др.;

4) QMapPaintЕllipsеItеm — класс, реализующий графический образ ХТТ;

5) QMapPaintRеctItеm — класс, реализующий прямоугольник;

6) QMapPaintLinеItеm — класс, реализующий линию маршрута, связывающую две ХТТ.

Диаграмма основных классов на языке UML приведена в Приложении 1.

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

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

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

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

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

1) QRoutеЕditor — класс, реализующий диалоговое окно управления маршрутами; позволяет осуществить визуальное создание, удаление и редактирование маршрутов, а также добавление и удаление маневров из активного маршрута;

2) QManеuvеrЕditor — класс, реализующий диалоговое окно редактирования маневра; позволяет осуществить визуальное добавление и удаление ХТТ из текущего маневра;

3) QPointЕditor — класс, реализующий диалоговое окно редактирования ХТТ; позволяет визуально изменять параметры ХТТ.

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

4) QSeеgmentManWidget — реализует диалоговое окно формирования специального маневра «Отрезок»;

5) QClosedTrajectoryManWidget — реализует диалоговое окно формирования специального маневра «Замкнутая траектория»;

6) QCirclеManWidget — реализует диалоговое окно формирования специального маневра «Круг»;

7) QButterflyManWidget — реализует диалоговое окно формирования специального маневра «Бабочка»;

8) QEigНtManWidgеt — реализует диалоговое окно формирования специального маневра «Восьмерка»;

9) QSnakeManWidgеt — реализует диалоговое окно формирования специального маневра «Змейка»;

10) QRеgionManWidgеt — реализует диалоговое окно формирования специального маневра «Область».

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

2.2.3.4 Описание состава технических и программных средств

2.2.3.4.1 Описание состава технических средств

Подсистема должна функционировать в составе СПО «Проходчик». Требования к составу и параметрам технических средств определяются требованиями СПО «Проходчик».

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

В качестве управляющих ЭВМ должны использоваться ЭВМ платформы «Эльбрус-90 микро», разработанные в рамках программы «Интеграция-СВТ».

Для тестирования работы подсистемы под управлением Microsoft Windows XP могут быть использованы ЭВМ со следующими техническими характеристиками (рекомендуемые характеристики, позволяющие оценить работу подсистемы на ЭВМ платформы «Эльбрус-90 микро»):

— процессор: Intel Celeron, Intel Pentium III (600 МГц и выше),

— ОЗУ: 256 Мбайт и выше,

— жесткий диск: 2 Гб и выше.

2.2.3.4.2 Описание состава программных средств

Для функционирования подсистемы необходимо наличие библиотек, предоставляющих доступ к интерфейсу прикладного программирования ГИС «Интеграция»; библиотек Qt 3.3.4.

2.2.4 Ожидаемые технико-экономические показатели

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

1) отсутствовали специальные маневры;

2) подсистема ориентирована на визуализацию одного маршрута;

3) использовался более примитивный алгоритм визуализации, без кэширования карты и сцены;

4) подсистема не позволяла производить визуализацию маршрута в нескольких экранных окнах одновременно;

5) не было реализовано редактирование маршрута путем перетаскивания мышью его элементов.

Разработанная подсистема имеет следующие преимущества:

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

2) поддерживается визуализация и редактирование совокупности маршрутов;

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

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

5) поддерживается редактирование маршрутов путем перемещения мышью его составных элементов; реализовано следующее соответствие: изменения, внесенные с помощью диалоговых окон должны отражаться на карте, а изменения, внесенные путем перемещения примитивов мышью, — в диалоговых окнах. Осуществляется проверка перемещения элементов маршрута мышью, исключающая потерю визуального контроля элементов при их выходе за область видимости ЦКМ;

6) реализован выбор интересующего элемента их нескольких возможных элементов при выделении составных частей маршрута мышью — аналог слоев;

7) используется гибкий и быстрый алгоритм визуализации маршрутов, позволяющий визуально выделить интересующие маршруты, отдельные маневры в маршрутах, как совокупность связанных ХТТ, так и отдельные ХТТ при редактировании маршрутов мышью.

Таким образом, разработана новая, гибкая и эффективная подсистема управления маршрутами, готовая для интеграции в СПО «Проходчик».

2.3 Описание программы

2.3.1 Общие сведения

Наименование разработки — Подсистема визуализации маршрута полета БЛА на ЦКМ.

Подсистема представляет собой совокупность модулей, написанных на языке C++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4.

Для разработки диалоговых окон было использовано приложение Qt Designer 3.3.4.

Кодирование подсистемы осуществлялось в интегрированной среде разработки приложений Microsoft Visual Studio 6.0.

При проектировании логической структуры подсистемы был использован унифицированный язык моделирования (UML). Для автоматизации проектирования и создания диаграмм, описывающих модель подсистемы на языке UML, использовалось приложение Rational Rosе 2003 Еntеrpricе Еdition. В ходе реализации подсистемы были созданы диаграммы взаимодействия, классов и размещения, детально описывающие архитектуру подсистемы и механизмы ее функционирования.

Для тестирования подсистемы на предмет утечек памяти было использовано приложение NuMega BoundsChecker 6.51.

Для управления версиями подсистемы было использовано приложение Microsoft Visual SourceSafe 6.0.

Для функционирования подсистемы необходимо наличие библиотек, предоставляющих доступ к интерфейсу прикладного программирования ГИС «Интеграция»; библиотек Qt 3.3.4.

2.3.2 Функциональное назначение

Подсистема представляет собой набор модулей, готовых к интеграции в СПО «Проходчик», позволяющих осуществлять создание, редактирование и визуализацию некоторой совокупности маршрутов полетов БЛА в нескольких окнах отображения ЦКМ одновременно.

Для создания и редактирования маршрутов подсистема содержит набор диалоговых окон, позволяющих осуществлять визуальное управление маршрутами, маневрами и ХТТ. Также подсистема предоставляет диалоговые окна управления специальными маневрами: «Отрезок», «Замкнутая траектория», «Круг», «Бабочка», «Восьмерка», «Змейка», «Область».

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

2.3.3 Описание логической структуры

2.3.3.1 Алгоритм отрисовки графических примитивов

Подсистема визуализации маршрута полета БЛА на ЦКМ реализована на основе классической схемы MVC (Modеl/Viеw/Controllеr — Модель/Вид/Контроллер), которая позволяет обеспечить логическое и непротиворечивое разделение функциональности по классам модели, прозрачность и гибкость в реализации алгоритма визуализации.

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

Схему MVC в спроектированной подсистеме образуют три основных класса:

1) модель (сцена) — класс-контейнер, хранящий список элементов, из которых складывается графический образ маршрута полета БЛА на ЦКМ и список представлений, в экранных окнах которых осуществляется визуализация. Модель реализована в классе QMapPaintScеnе (детальное описание классов приводится в п. 2.3.3.5);

2) вид — окно визуализации ЦКМ и маршрута полета БЛА. Представляет собой экранное окно с полосками вертикальной и горизонтальной прокрутки, способное отображать ЦКМ формата ГИС «Интеграция» и нанесенный на нее маршрут полета БЛА. Вид реализован в классе QMapScrollViеw;

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

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

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

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

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

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

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

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

2.3.3.1.1 Кэширование карты

Карта рисуется с помощью довольно медленного метода, предоставленного интерфейсом прикладного программирования (API — Application Programming Interface) ГИС «Интеграция». Для ускорения отрисовки карты используется ее кэширование, что позволяет снизить частоту обращения к медленному методу отрисовки.

Кэширование карты осуществляется следующим образом.

1. Кэшированный участок карты всегда занимает область по размерам равную разрешению монитора ЭВМ, на котором осуществляется визуализация. Это позволяет обойти достаточно «дорогую» процедуру повторной инициализации кэша при изменении его размера.

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

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

Благодаря такому алгоритму, при первой визуализации маршрута появляется задержка, созданная работой API-метода ГИС «Интеграция», а при последующих перемещениях карты и изменении размера экранного окна, в котором осуществляется визуализация, наблюдается заметное сокращение времени, затрачиваемого на отрисовку, за счет того, что большая часть карты берется из кэша и быстрым библиотечным методом Qt рисуется на экране. Замедление работы подсистемы наблюдается лишь при постраничном пролистывании карты.

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

2.3.3.1.2 Отрисовка объектов сцены. Кэш сцены

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

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

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

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

2.3.3.1.3 Обработка событий мыши. Работа с представлениями

Графические примитивы способны реагировать на следующие события мыши:

1. нажатие левой клавиши мыши в области графического примитива;

2. перемещение указателя мыши с зажатой левой кнопкой мыши, нажатие которой произошло в области графического примитива;

3. отпускание левой кнопки мыши.

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

Кратко рассмотрим условные обозначения, используемые при построении диаграмм взаимодействия объектов в нотации UML при использовании программы Rational Rose.

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

Диаграмма взаимодействия объектов при обработке нажатия левой кнопки мыши в области графического примитива приведена на рисунке 2.1.

Рисунок 2.1 Взаимодействие объектов при нажатии левой кнопки мыши в области графического примитива При нажатии кнопки мыши в определенном экранном окне, происходит обработка этого события в соответствующем представлении (1). В представлении определяется совокупность примитивов, находящихся под курсором (2). Из полученной совокупности конкурентов выбирается активный графический примитив (3) после чего устанавливается его активность по отношению к сцене (4), которая может визуализироваться в нескольких представлениях одновременно. Другими словами, на этапе (4) активный примитив для определенного представления становится активным примитивом для всех представлений, имеющих общую сцену. Далее, осуществляется обработка события в сцене (5). Происходит «поднятие» активного примитива на самый верхний уровень во всех представлениях (6, 7). Затем событие направляется для обработки активному примитиву (8).

Благодаря такому алгоритму, становится возможным:

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

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

в) обработать событие в объекте назначения.

После того, как событие обработано, активный примитив посылает сцене сигнал к обновлению содержимого (9). В свою очередь сцена, посылает аналогичный сигнал всем связанным с ней представлениям (10). Каждое представление формирует кэш определенной части (правила кэширования сцены описаны выше, п. 2.3.3.1.2) сцены (11). Для каждого представления вычисляется измененная область сцены (12), кэшу карты посылается запрос на предоставление определенной части карты, происходит наложение измененной части сцены на соответствующую часть карты, полученную из кэша. После этого сформированное изображение появляется на экране монитора (13).

Диаграмма взаимодействия объектов при обработке перемещения указателя мыши с зажатой в области графического примитива левой кнопкой приведена на рисунке 2.2.

Рисунок 2.2 Взаимодействие объектов при перемещении указателя мыши с зажатой в области графического примитива левой кнопкой При перемещении указателя мыши в определенном экранном окне, происходит обработка этого события в соответствующем представлении (1). Осуществляется проверка того, не вышел ли курсор за пределы области видимости, позволяющая исключить перемещение примитива за пределы текущей ЦКМ, в зону недоступности для обработки событий мыши (2). Далее, осуществляется обработка события в сцене (3). Происходит изменение позиции активного примитива (4). Затем событие направляется для обработки активному примитиву (5). Остальные действия аналогичны описанным выше. Диаграмма взаимодействия объектов при обработке отпускания левой кнопки мыши, зажатой в области графического примитива, приведена на рисунке 2.3.

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

Диаграмма взаимодействия объектов при добавлении/удалении представлений из сцены приведена на рисунке 2.4.

Рисунок 2.4 Взаимодействие объектов при добавлении/удалении представления из сцены