Содержание к диссертации
Введение
1. Разработка подхода к проектированию ПО системы визуализации 9
1.1. Общая характеристика задачи 10
1.2. Подход к проектированию системы визуализации 13
1.3. Структура типового тренажерного комплекса 16
1.4. Выделение подсистем системы визуализации 22
1.5. Основные типы объектов системы визуализации 25
1.6. Постановка задачи исследования 29
2. Методы проектирования ПО системы визуализации 31
2.1. Повторное использование исходного кода 32
2.2. Повторное использование классов 33
2.3. Повторное использование компонентов 38
2.4. Повторное использование образцов 40
2.5. Повторное использование каркасов 42
2.6. Оценка методов повторного использования 45
2.7. Разработка метода проектирования систем визуализации 48
2.8. Выводы 51
3. Разработка модели системы визуализации 53
3.1. Разработка обобщенной модели основных подсистем 54
3.1.1. Запуск и настройка системы визуализации 55
3.1.2. Иерархическая структура для хранения объектов сцены 59
3.1.3. Отображение объектов сцены 63
3.1.4. Поддержка моделей движения объектов 66
3.1.5. Разделяемые модели объектов 68
3.1.6. Обобщенная модель системы визуализации 71
3.2. Разработка модели сетевой подсистемы 74
3.2.1. Типы данных 75
3.2.2. Передача данных в сетевой модуль 79
3.2.3. Передача данных клиенту 82
3.2.4. Организация хранения команд 85
3.2.5. Отправка команд получателю 86
3.2.6. Общая структура сетевой подсистемы 90
3.3. Выводы 94
4. Проект системы визуализации для тренажера операторов подводного аппарата 95
4.1. Методика создания системы визуализации на основе каркаса 96
4.1.1. Управляющая подсистема 96
4.1.2. Подсистема загрузки графических моделей 98
4.1.3. Подсистема движения объектов 99
4.1.4. Подсистема хранения и отображения объектов 99
4.1.5. Сетевая подсистема 100
4.2. Общее описание имитатора ТВК подводного аппарата 102
4.3. Оценка эффективности разработанного каркаса 105
4.4. Методика оценки производительности имитатора ТВК 107
4.5. Выделение подзадач имитатора ТВК ПО
4.6. Оценка производительности системы на базе каркаса 112
4.7. Анализ производительности имитатора ТВК 118
4.8. Выводы 122
Заключение 123
Список литературы 124
- Структура типового тренажерного комплекса
- Разработка метода проектирования систем визуализации
- Обобщенная модель системы визуализации
- Общее описание имитатора ТВК подводного аппарата
Введение к работе
Актуальность. Эксперименты по применению средств машинной графики начались около 35 лет назад в тренажерах военно-транспортной техники [17]. Благодаря резкому снижению стоимости компьютеров и повышению их производительности, применение машинной графики стало повсеместным. Более того, решение задач синтеза изображений может выполняться уже без применения дорогостоящего специализированного оборудования - на базе серийных персональных компьютеров.
Возможность использования ПК стимулировала развитие тренажеростроения и привела к созданию большого числа тренажеров для всех сред, в которых передвигается человек. Задача поддержания и совершенствования необходимых навыков у экипажей различных технических аппаратов достаточно актуальна в данный момент и вряд ли в ближайшем будущем потеряет свою актуальность. Следовательно, необходимость соответствия используемого тренажерного парка современному уровню техники неизбежно приведет к созданию новых тренажерных комплексов и модернизации уже существующих.
В состав любого компьютерного тренажера входит система визуализации, изображающая окружающую среду, в рамках которой функционирует имитируемое техническое средство. Данная система также может отображать и контрольно-управляющую часть кабины, если в тренажере не предусмотрена механическая часть, имитирующая такую кабину.
Создание новых тренажеров влечет за собой необходимость разработки новых систем визуализации. Создание каждой следующей системы с нуля является неэффективным, поскольку требует серьезных затрат. В связи с этим появляется необходимость использования подхода к проектированию систем визуализации, основанного на выделении общих элементов в составе системы визуализации. Выделенные общие элементы могут быть спроектированы однократно и, затем, многократно использоваться в последующих системах. Подобный подход к проектированию программного обеспечения широко распространен и позволяет уменьшить время и стоимость разработки соответствующего ПО, а также сократить количество ошибок в нем. Тем не менее, имеет место недостаток информации относительно применения данного подхода к созданию систем визуализации тренажеров.
Предлагаемая работа посвящена проблемам повышения эффективности проектирования систем визуализации тренажеров. Данная задача представляется весьма актуальной, поскольку разработка моделей проектирования позволит сократить время и стоимость создания систем визуализации.
Целью работы является разработка обобщенной модели системы визуализации тренажера. Достижение указанной цели предполагает решение следующих задач: разбиение системы визуализации на общую и специализированную части с выделением основных задач и объектов, характерных для данной предметной области; анализ и разработка методов проектирования систем визуализации; проектирование архитектуры системы визуализации для решения выделенных типовых задач; реализация спроектированной модели и создание на ее базе системы визуализации тренажера подводного аппарата; - оценка эффективности реализации обобщенной модели. Основные методы исследования. Для решения поставленных задач применялись методы интерактивной машинной графики [36], методы проектирования программного обеспечения [1, 3, 16, 35], а также методы проектирования и оценки производительности систем реального времени [13].
Научная новизна.
Предложен оригинальный метод к проектированию системы визуализации;
Разработана обобщенная модель проектирования для системы визуализации, описывающая базовую архитектуру данной системы.
Практическая ценность работы.
Разработан каркас системы визуализации тренажера;
Реализованы и внедрены три программных системы визуализации подводной обстановки с использованием каркаса;
Произведен анализ эффективности созданного каркаса системы визуализации.
Апробация работы. Основные положения работы представлялись и обсуждались на семинарах кафедры Вычислительной Техники СПбГЭТУ и Научно-проектного центра оптоэлектронных комплексов наблюдения (С. - Петербург, 2003).
Структура и объем работы. Диссертация состоит из введения, четырех разделов, заключения, списка литературы, включающего 63 наименования, и приложения. Работа содержит 114 страниц основного текста, 30 иллюстраций и 14 таблиц.
В первом разделе дается краткое описание особенностей организации тренажеров. Рассматриваются основные типы объектов, используемых системой визуализации, и минимальный набор параметров необходимый при задании этих объектов. Приводится набор подсистем, составляющих систему визуализации. Сформулирован подход к проектированию систем визуализации тренажеров. Выделены основные задачи, требующие разрешения для создания многократно используемой архитектуры системы визуализации тренажерного комплекса.
Второй раздел посвящен анализу различных методов проектирования системы визуализации. Рассматривается возможность применения данных методов при разработке ПО системы визуализации тренажера и получаемая при этом степень многократного использования элементов системы. На основании проведенного исследования предлагается оригинальный метод проектирования, используемый в дальнейшем при разработке обощенной модели системы визуализации.
В третьем разделе рассматривается процесс разработки обобщенной модели системы. Предлагаются варианты архитектуры для основных подсистем и блоков, включаемых в систему визуализации.
Четвертый раздел посвящен оценке эффективности разработанного каркаса системы визуализации. Для этого производится оценка достигнутого уровня повторного использования. Также приводится методика оценки производительности системы и иллюстрация ее применения на примере системы визуализации подводной обстановки.
Структура типового тренажерного комплекса
В данной таблице П - это пульт управления, генерируемый программным обеспечением системы визуализации и отображаемый на мониторе; Р - пульт управления, представленный реальными органами управления имитируемого средства; М - отображение окружающей обстановки выполняемое на мониторе ПК для каждого из операторов; О - использование оптико-коллимационных устройств для визуализации; N/A - нет данных.
Механическая часть тренажера представляет собой макет кабины имитируемого технического средства (кабина самолета/вертолета, корпус автомобиля/мотоцикла, рубка надводного корабля и т. п.). Такой макет способствует более полному погружению оператора в виртуальное пространство решаемой задачи. Часто макет кабины устанавливается на подвижную платформу, управляемую цифровым вычислительным комплексом, что позволяет имитировать различные акселерационные эффекты, действующие на оператора: перегрузки, угловые скорости и ускорения. Использование подвижной платформы характерно, в основном, для авиационных тренажеров и для морских комплексов применяется редко.
Пульт управления позволяет оператору воздействовать на характеристики имитируемого объекта. Организация пульта управления может быть различной. В простейшем случае он представляет собой серийный ПК, устройства ввода которого (клавиатура, мышь, джойстик и т. п.) оператор использует для управления имитируемым техническим средством. При этом само изображение пульта генерируется ПО системы визуализации и выводится на мониторе. В наиболее сложном случае в качестве пульта используются реальные органы управления соответствующего технического средства. Как правило, такая организация пульта управления характерна для тренажеров, в которых используется механическая часть.
Система визуализации обеспечивает генерацию 3-мерного изображения виртуальной окружающей обстановки. В простейшей системе визуализации отображение сцены производится на мониторе серийного ПК, за которым работает оператор. В наиболее сложном случае отображение выполняется с применением многоканальной системы и оптико-коллимационных устройств, позволяющих обеспечить угол обзора вплоть до 360 градусов.
Набор моделей функционирования содержит описание работы объекта и его бортовых систем в различных ситуациях. Для случая морского тренажера это могут быть модели функционирования разного рода энергоустановок, гидроакустических и навигационных комплексов, систем вооружения и т. п.
Проектирование и реализация таких моделей всегда является одной из наиболее сложных и трудоемких задач при создании тренажера. Эта модель должна увязать рассматриваемый параметр par є Р для конкретного объекта среды с остальными параметрами из множества параметров Р. В общем случае модель может задавать некий переходный процесс, который возникает в системе при изменении данного параметра. Очевидно, что для сложного тренажерного комплекса необходим целый набор таких моделей, которые бы связали различные подмножества параметров из Р и обеспечили реалистичное функционирование объектов внутри созданной виртуальной реальности. Входом для таких моделей будет некоторое множество параметров Р-ш с: Р. В простейшем случае входное множество параметров будет ограничиваться только одним измененным параметром. В самом общем случае оно может совпадать с Р. Это произойдет в случае, когда задаваемый моделью процесс будет зависеть от всех параметров окружения. Поскольку любой переходный процесс, происходящий в моделируемой системе, предполагает зависимость от времени, то этот параметр также должен быть задан на входе модели. На выходе модели в каждый момент времени / будут новые значения параметров из множества Pout с Р, определяющих новое состояние объектов окружения, которых коснулось изменение.
Набор графических моделей объектов содержит описание внешнего вида объекта, которое используется при его отображении системой визуализации.
Управляющий вычислительный комплекс обеспечивает координацию действий различных подсистем (акселерационной, визуальной, акустической, приборной) для имитации синхронности изменений.
Оператор является центральным звеном всего тренажерного комплекса и осуществляет управление объектами создаваемой виртуальной реальности. Управление любым объектом моделируемой обстановки осуществляется путем изменения его параметров. Каждый оператор имеет четко определенный набор функций по управлению тем или иным объектом, то есть для тренажера существует вполне определенное соответствие Go с МхР, где М - это множество операторов тренажера, а Р - множество всех параметров для всех объектов из О: Р = u par i, где к є [1, n] n N, і є [1, m] n N. Это соответствие будет определять, кто из операторов какие параметры среды может изменять. Если каждому оператору доступны все параметры объекта, это соответствие может быть задано в следующем виде: G\ = МхО. В этом случае, соответствие будет определять, кто из операторов каким объектом может управлять.
Помимо операторов каждый тренажер имеет одно или несколько рабочих мест инструктора. Инструктор или команда инструкторов выполняет общее управление тренировочным процессом: определяет задачу тренировки, задает начальные условия, параметры окружающей среды, а также имеет возможность наблюдения за генерируемой виртуальной обстановкой и действиями операторов.
Разработка метода проектирования систем визуализации
Основной недостаток метода повторного использования компонентов заключается в недоступности исходных кодов. Это приводит к сложности модернизации компонента и всей системы в целом. По этой причине данный метод также не может рассматриваться в качестве основного, несмотря на обеспечиваемый высокий уровень повторного использования.
Таким образом, в качестве возможных методов для создания ПО системы визуализации целесообразно применять методы повторного использования классов, образцов или каркасов. Метод повторного использования каркасов фактически является расширением метода применения образцов, который, в свою очередь, расширяет метод повторного использования классов. Соответственно, применение каркаса обеспечивает максимальный для этих трех методов уровень повторного использования в системе. Оформление общей части системы визуализации в виде каркаса позволит обеспечить многократное использование ядра системы как единого целого со всеми необходимыми внутренними взаимосвязями, а не как набора разрозненных классов или образцов.
Разработка каркаса обычно ведется путем обобщения конкретных приложений в соответствующей предметной области. В данном конкретном случае - путем обобщения различных систем визуализации. Чем большее количество таких систем будет проанализировано при создании каркаса, тем более общим он получится. Однако процесс проектирования каркаса достаточно сложен, поэтому попытка построения каркаса на основе большого количества приложений может не увенчаться успехом. Даже в случае успеха подобная работа потребует больших затрат времени. Поэтому проектирование каркаса, как правило, выполняется путем обобщения всего 2-3 приложений. Создание даже относительно простого каркаса позволяет облегчить создание новых систем визуализации. Кроме того, разработав первую версию каркаса, появится возможность анализировать создаваемые с его помощью приложения и дополнять каркас по мере необходимости.
Построенный на основе 2-3 приложений каркас, как правило, управляется архитектурой и носит название architecture-driven framework или white-box framework [31]. Для того, чтобы использовать его разработчик должен достаточно хорошо изучить классы, объекты и взаимосвязи в рамках данного каркаса, а затем с использованием наследования добавить необходимый специфический код. На создании управляемого архитектурой прототипа развитие каркаса может не заканчиваться. В соответствии с описанием этапов эволюции каркаса, приведенным в [32] это лишь первая ступень в его развитии. По мере эволюции созданный каркас может быть преобразован в генератор систем данной предметной области, оснащенный графическим интерфейсом. Этот интерфейс позволяет пользователю определить, какие объекты должны быть реализованы в каркасе и как они должны взаимодействовать. Далее, на основе этой спецификации создается исходный код каркаса.
Генератор помимо собственно описания каркаса должен включать в себя множество других составляющих, которые облегчают работу с ним. Как минимум это должны быть графический интерфейс пользователя, генератор спецификации для создания каркаса по данным пользователя и генератор каркаса на основе спецификации. Для множества каркасов создание этих элементов не является оправданным. Поэтому данного этапа достигают только хорошо апробированные каркасы, получившие широкое распространение.
По этой причине говорить о создании генератора для системы визуализации еще преждевременно и основной задачей, которую предлагается решить в рамках данной работы является создание первой версии управляемого архитектурой каркаса.
Основная проблема, возникающая при использовании каркаса, заключается в том, что данный метод регламентирует только взаимосвязи между универсальной и специализированной частью системы, никак не определяя внутреннюю организацию универсальной части. Следовательно, несмотря на обеспечиваемый высокий уровень повторного использования, метод не гарантирует простоту расширения и модификации системы. Этот недостаток делает неэффективным применение данного метода в чистом виде и требует комбинированного метода, который бы позволил обеспечить простоту расширения системы при сохранении имеющегося уровня повторного использования. Создание комбинированного метода было выполнено путем объединения метода повторного использования каркасов и образцов. В данном случае взаимодействие универсальной части со специфической будет регламентировано методом повторного использования каркасов, а внутренняя организация каркаса будет представлена совокупностью образцов.
Тем не менее даже эта модернизация не гарантирует автоматическое создание жизнеспособной архитектуры для системы визуализации, поскольку ее качество будет полностью зависеть от опыта архитектора. Использование унифицированного процесса проектирования ПО, разработанного Rational Software, и стандарта UML также не позволяет полностью решить эту проблему. При всех преимуществах унифицированного процесса, он дает только самые общие рекомендации, применимые к разработке практически любого программного обеспечения. Соответственно, учет специфики предметной области систем визуализации целиком лежит на архитекторе приложения. В первую очередь это относится к декомпозиции системы, поскольку для проектирования каркаса на уровне образцов уже должно существовать его детальное описание. Один из возможных методов проектирования состоит в определении имен существительных в документах технического задания и ассоциировании класса с каждым существительным, как, например, рекомендовано в [62]. Функциональные возможности системы моделируются обменом сообщениями между соответствующими классами. Этот метод проектирования, однако, может привести к слишком запутанной программной архитектуре [59]. С другой стороны, спецификация параграфа 1.3 позволяет явно выделить 4 группы объектов, из которых конструируется верхний уровень архитектуры системы визуализации. Такими группами являются набор данных, модули ввода\вывода данных, обработчики и управляющие модули.
Обобщенная модель системы визуализации
Отображение объекта внутри трехмерной сцены невозможно без знания его координат и ориентации в пространстве. Для корректного выполнения этой операции все объекты должны быть заданы в единой (мировой) системе координат. Если объект движется, то координаты всех его вершин в этой системе постоянно изменяются. Очевидно, что это чрезвычайно неудобно. Гораздо проще измерять координаты объекта в локальной системе данного объекта, а перед отображением пересчитывать их в мировую систему. Этот процесс обычно называется мировым преобразованием и требует специальной матрицы (матрица мирового преобразования), на которую умножаются все координаты. Подобная организация используется повсеместно и позволяет объекту не знать о своем положении в пространстве. Данная информация может быть добавлена в последний момент перед отображением объекта.
Для составных объектов этот подход можно распространить и на подобъекты. Это позволит задавать подобъект в своей локальной системе координат, а не в системе объекта-родителя. В этом случае при формировании матрицы мирового преобразования можно действовать двумя путями. Первый путь заключается в рассмотрении подобъекта отдельно от объекта-родителя. Соответственно, матрица подобъекта будет формироваться независимо от объекта-родителя. Очевидно, что такой подход является достаточно опасным, так как в случае ошибок в одной из матриц объект-родитель и подобъект могут оказаться в различных местах сцены. Второй путь более безопасен. Он предполагает привязку подобъекта к объекту-родителю. В этом случае его местоположение задается относительно родителя. Подобъекту необходимо знать только о том, что он расположен со смещениями (dx, dy, dz) относительно объекта-родителя в его локальной системе координат и повернут относительно него на углы (ф, в, у/). Для получения полной матрицы мирового преобразования необходимо матрицу подобъекта, заданную относительно родителя умножить на матрицу самого родителя. Таким образом, в общем случае для получения итоговой матрицы подобъекта его собственная матрица должна быть умножена на матрицы всех его родителей. В качестве примера можно рассмотреть моделирование подъемного крана. Положение крана внутри сцены можно задать некоторой матрицей А. Положение башни крана относительно его платформы задается матрицей В. Наконец, положение стрелы относительно башни будет задано матрицей С. В этом случае отображение крана сведется к набору следующих операций: 1. Создание матрицы А и отображение платформы крана; 2. Создание матрицы В и отображение башни крана (как Д В); 3. Создание матрицы С и отображение стрелы (как Д В. С). Уже из приведенного примера видно, что для выполнения указанных операций наиболее удобно использовать стековую организацию. В этом отношении использование древовидной структуры из параграфа 3.1.2 для хранения объектов является очень удобным. Обработку этого дерева можно начать с корневого объекта и выполнить обход по глубине. При этом в начале обработки каждого объекта его матрица заталкивается в стек и выталкивается оттуда только после обработки всех потомков данного объекта. Создание такого рода стеков может выполняться либо собственными средствами, либо с использованием стандартных интерфейсов из числа предоставляемых графическими библиотеками (например, ID3DXMatrixStack в DirectX SDK). После вычисления матрицы мирового преобразования объекта он может быть отображен. Однако если для вычисления матриц или управления объектами древовидная структура была удобной, то для отображения сцены данная организация удобной не является. Дерево объектов сцены содержит все ее объекты, а отображаться должны только графические. Более того, параметры светильников и камер должны быть известны заранее и установлены до начала отображения. Соответственно, для каждого отображения сцены потребуется по N+1 обходов дерева: на первом обходе вычисляются параметры камер и светильников, следующие N обходов выполняют отображение графических объектов сцены для соответствующей активной камеры. Здесь N - это количество активных камер, то есть камер, чье изображение выводится на монитор в данный момент.
Очевидно, что основное время тратится на N обходов дерева для отображения сцены на активных камерах. Полностью избежать перебора графических объектов не удастся, так как параметры камеры влияют на видовое и проекционное преобразования вершин объекта. Однако существует возможность ускорить этот процесс. Для этого кроме дерева объектов сцены требуется сформировать планарный список указателей на графические объекты. Наличие такого списка позволит вместо N обходов дерева, в котором содержатся все объекты, выполнять N обходов плоского списка, в котором содержатся только графические объекты.
Таким образом, при хранении объектов наиболее удобным является задание их координат в локальной системе. Это позволяет объекту и его подобъектам ничего не знать о своем положении в пространстве. Информация об этом потребуется только в момент отображения объекта и может храниться отдельно от множеств вершин и треугольников объекта. Подобная организация достаточно широко используется в различных системах визуализации и позволяет использовать заранее созданные модели сложных графических объектов. В связи с этим, описанная в предыдущем параграфе структура хранения объектов очень удобна, так как позволяет с помощью стека выполнить преобразование координат объекта в мировую систему.
Однако для отображения объектов дерево не является очень удобным, так как в нем хранятся все объекты сцены, а отображаться должны только графические. Для решения этой проблемы можно предложить дополнительный список, хранящий указатели на графические объекты. В этом случае для отображения сцены сначала выполняется один обход дерева с вычислением матриц мирового преобразования объектов и назначением светильников, освещающих сцену. Затем выполняется N обходов списка графических объектов, в течение которых производится отображение этих объектов на всех активных камерах.
Общее описание имитатора ТВК подводного аппарата
Подсистема хранения и отображения объектов определяет основные типы объектов для системы визуализации и возможные операции с ними. Для создания объекта разработчик должен унаследовать класс своего объекта от CSimpleObject или CComplexObject. Решение о том, от какого из них необходимо унаследовать создаваемый класс зависит от того, может ли данный тип объектов иметь дочерние объекты или нет. Для классов объектов, которые в зависимости от условий могут иметь дочерние объекты, а могут не иметь рекомендуется выбирать наследование от CComplexObject.
Основным методом, который должен быть предоставлен разработчиком для применения классов CComplexObject и CSimpleObject, является метод Render, отображающий данный объект. В случае использования графической модели объекта этот метод может делегировать выполнение операции классу модели (например, CXFileTemplate для DirectX файлов).
В разработанном каркасе предполагается, что экземпляры камер и светильников также включаются в общее дерево сцены и могут быть как листовыми, так и контейнерными объектами. При создании таких объектов разработчик может подмешивать к CComplexObject или CSimpleObject классы из следующего набора: CCamera, CPointLight, CDirectionalLight, CParallelPointLight и CSpotLight. Основные параметры этих типов объектов рассматривались в параграфе 1.5.
Сетевая подсистема обеспечивает передачу информации между узлами, входящими в состав тренажера. Универсальная часть данной подсистемы включает интерфейсы приема и выдачи команд клиентам, обеспечивает хранение, разбиение команд на пакеты, отправку и прием данных из сети.
Для использования сетевой подсистемы от разработчика в первую очередь требуется создания класса, реализующего интерфейс CNetCmdRouter. Данный класс определяет списки кодов команд, которые данный узел должен принимать или посылать на другие узлы в сети. В зависимости от требований к системе этот класс может задавать статическую или динамически изменяющуюся таблицу соответствий между кодом команды и номерами сетевых узлов, на которые эта команда должна отсылаться и с которых она должна приниматься. Интерфейс содержит 3 метода: IsSendNeed, IsStateCommand и GetNodesForCommand. Метод IsSendNeed должен определить необходима ли передача команды по сети. Если такая передача необходима, метод GetNodesForCommand должен вернуть список узлов, на которые эта команда должна быть отправлена.
Для получения уведомлений о приходе команды клиентский класс должен поддерживать интерфейс Subscriber. Этот интерфейс декларирует единственный метод - Notify, который будет вызываться при получении команды. Подписка и удаление подписки на команду с каким-либо кодом осуществляется путем вызова методов Subscribe и Unsubscribe соответственно. На данный момент каркас поддерживает передачу данных с использованием протоколов TCP и UDP. Для реализации специфических схем обмена разработчик может реализовать собственный адаптер. Для этого необходимо выполнить создание класса адаптера (унаследованного от CACEAdapter) и класса буфера команд (унаследованного от CCtrlCmdBuf f ег или CStateCmdBuf fer), который будет работать с этим адаптером. В примере из приложения 1 тренажер состоит из двух узлов. Узел №1 является управляющим и выдает второму сетевому узлу текущие координаты и ориентацию корпуса корабля и радара. Узел №2 обеспечивает управление камерной установкой и возвращает текущую ориентацию и параметры наблюдения. В соответствии с параграфом вся информация оформляется в виде команд состояния. Приложение содержит пример исходного кода для узла №1 и обеспечивает передачу структур CruiserData и RadarData на второй узел, а также принимает структуру CamData и выполняет необходимую корректировку параметров наблюдения в методе CCruiserCamera::Notify. Приведенный в данном параграфе список методов представляет собой минимальный набор функций, который должен быть задан разработчиком для получения работоспособной системы визуализации. При необходимости этот список может быть расширен. На основе реализованного каркаса было выполнено создание системы визуализации тренажера подводного аппарата. Разработанная система предназначалась для имитации работы телевизионного комплекса (ТВК) подводного объекта в процессе поиска и классификации объектов наблюдения. Тренажер предусматривает два рабочих места операторов, имеющих специфичный набор функций по управлению имитируемым подводным объектом и пост руководителя обучением (рис. 4.2.2). Система визуализации каждого из операторов (СВ1, СВ2) имитирует видеоинформацию, получаемую с нескольких камерных установок ТВК, которая включает в себя изображение поверхности морского дна и различные затонувшие предметы (рис. 4.2.1 а, б, в), объекты в толще воды, а также надводную обстановку (рис. 4.2.1 г). Оператор движения с помощью клавиатуры системы визуализации или штатного пульта (ПУ) обеспечивает управление имитируемым подводным объектом в режиме поиска затонувших объектов. В случае обнаружения соответствующего затонувшего предмета одной из его основных задач является маневрирование подводным объектом с целью выхода на позицию, создающую наилучшие условия для его наблюдения и классификации.
