CC BY
62
использования в ЗОС МСВС, как показала практика разработки изделий, не оказывает существенного влияния на увеличение сроков выполнения работ и качество выпускаемого программного изделия.
Литература
1. Хоффман Б., Мартин К. Разработка программного обеспечения в небольшой организации (http://www.osp.ru/os/2007/03/4158385).
2. Лапыгин Д., Новичков А. Конфигурационное управление проектами разработки программного обеспечения (http://www.citfo-rum.ru/SE/quality/configuration_management).
ВАРИАНТЫ ВЗАИМОДЕЙСТВИЯ РАБОЧИХ МЕСТ ТАКТИЧЕСКОГО ТРЕНАЖЕРА
А.Б. Шорин; И.В. Новиков (НИИ «Центрпрограммсистем», г. Тверь, [email protected])
Ключевые слова: система моделирования, АРМ, синхронизация данных, клиент модели, адекватность моделирования, активный и пассивный объекты.
В состав тактического тренажера входят центральный пост руководства обучением, центральный вычислительно-моделирующий комплекс (ВМК) и АРМ обучаемых (АРМО).
ВМК - это распределенная система моделирования, функционирование которой строится по принципу клиент/сервер. Сервер ВМК отвечает за инициализацию системы моделирования (на основе задания на тренировку), управление единым временем тренажера, добавление и удаление моделей. Сервер ВМК в составе тренажера существует в единственном экземпляре. Клиент ВМК связывается с сервером и получает сведения о модельном времени, о состоянии тренировки и моделей тактической обстановки. Клиентов ВМК может быть множество. Как сервер, так и клиент ВМК реализуются в виде динамической библиотеки и предоставляют доступ ко всем сервисам ВМК. Данная библиотека используется также и приложениями, реализующими АРМО.
ВМК состоит из исполнительной системы и библиотеки имитационных моделей.
Моделирование тактической обстановки предполагает имитацию широкого спектра разнородных объектов, процессов и явлений. Перечень объектов моделирования нестабилен и может быть расширен в процессе разработки. Система моделирования предполагает максимальное отделение моделей от остальных компонентов системы и формализацию способов взаимодействия моделей. Исполнительная система располагает минимальным объемом информации о моделях, благодаря чему может работать с разнородным составом моделей. Данный подход позволяет произвольно масштабировать систему. Моделирование тактической обстановки с точки зрения ВМК - это процесс взаимодействия моделей, причем способ взаимодействия определяется самими моделями. Исполнительная система обеспечивает распределение моделей по узлам вычислительной сети тренажера и выполнение моделей.
Центральным понятием системы моделирования является модель объекта (системы). Все моде-
ли реализуются в отдельных модулях, которые динамически загружаются в ходе инициализации системы моделирования. Дополнение и изменение программных модулей имитационных моделей возможно как при разработке комплекса, так и при его модернизации.
Современный тактический тренажер - это распределенная вычислительная система. Результаты моделирования объектов обстановки должны быть доступными на всех вычислительных узлах сети. Для этого каждая модель реализует возможность функционирования в двух режимах - клиента и сервера. На одном узле сети функционирует сервер модели, который осуществляет собственно процесс моделирования. На остальных узлах работает клиент модели, предоставляющий доступ к результатам моделирования и передающий запросы пользователей модели серверу.
Сервис сетевого взаимодействия моделей, предоставляемый ВМК, решает вопросы синхронизации данных моделируемых объектов. Сервис предоставляет функции передачи данных с серверного экземпляра модели всем существующим в тренажном комплексе клиентским экземплярам модели (синхронизация клиентов), передачи данных от клиентского экземпляра модели серверному экземпляру (команды управления) и адресной передачи данных от любого экземпляра модели любому указанному экземпляру (адресное сообщение). Первые две функции освобождают разработчика модели от знания расположения серверного экземпляра и знания расположения и количества клиентских экземпляров моделей.
Принципиально модель реализуется в виде неделимого программного объекта, который может функционировать в одном из двух режимов -серверном и клиентском. За счет этого достигается возможность гибкого конфигурирования процесса моделирования: сервер модели может работать на любом вычислительном узле. Программы, использующие модель, принципиально не должны заботиться о том, в каком режиме она функционирует.
Как правило, АРМО тактического тренажера имитируют отдельные системы одного объекта тактической обстановки (например, подводной лодки). Такой объект будем называть активным. Объекты, моделируемые ВМК, называем пассивными.
Основная задача модели активного объекта -осуществить взаимодействие между рабочими местами тренажера и пассивными объектами. Модель активного объекта реализуется по тем же правилам системы моделирования, что и модели пассивных объектов, и поддерживает архитектуру клиент/сервер.
Рассмотрим пример реализации модели активного объекта - подводной лодки. АРМО реализуют соответствующие пульты управления систем конкретного проекта. Сервер модели активного объекта будет размещен на одном из АРМО или отдельном сервере. Сервер модели осуществляет взаимодействие с АРМО. Это взаимодействие может быть реализовано любым способом на усмотрение разработчика модели. На рисунке 1 приведен пример распределенной модели на узлах вычислительной сети тренажера без уточнения способа взаимодействия сервера модели с АРМО.
Взаимодействие сервера с АРМО может быть осуществлено аналогично его соединению с ВМК и постом руководства обучением. Для реализации необходимо только использование клиента ВМК АРМО. Клиент ВМК, расположенный на АРМО, будет содержать в себе клиента модели активного объекта.
Модель активного объекта предоставляет данные о параметрах движения активного объекта, состоянии и режимах функционирования его систем, об обнаруженных целях, параметрах гидроакустических и радиолокационных полей посредством реализации соответствующих интерфейсов. В целом модель активного объекта должна реали-зовывать все интерфейсы пассивного объекта, в том числе свои специфические.
Набор поддерживаемых программных интерфейсов определяет разработчик модели на этапе ее проектирования. При этом он может описать и
ВМК Сервер ВМК
Клиент модели активного объекта
Пост руководства обучением Клиент ВМК
Клиент модели активного объекта
Сервер Клиент ВМК
Сервер модели активного объекта
II
АРМО 1 АРМО 2 АРМО N
Рис. 1
реализовать собственные интерфейсы, которые будут известны только специализированным программам и моделям. Например, модели систем активного объекта могут поддерживать специфические интерфейсы для взаимодействия между собой. Модель активного объекта реализуется в виде библиотеки и регистрируется в базе данных. После этого ее можно добавлять в тактическую обстановку.
Модель может предоставлять окно редактирования параметров объекта в специальную программу «Универсальный редактор базы данных». Набор и способ отображения данных на окне определяется исключительно разработчиком модели. Например, окно может отображать информацию о тактико-технических характеристиках объекта или внешний вид (фотографию) объекта.
Модель должна предоставлять окно управления на посту руководства обучением, которое позволяет задавать начальное состояние объекта (распределение боезапаса, состояние средств обнаружения и т.д.). Во время проведения тренировки окно используется для мониторинга систем объекта, а также дает возможность управлять объектом с помощью команд, которые отправляются на сервер модели.
Модель также должна реализовывать интерфейс, посредством которого отображается графика на экране поста руководства обучением. Модель должна самостоятельно рисовать графическое изображение моделируемого объекта (условное обозначение), кроме того, она может отображать произвольную дополнительную информацию, например, зоны обнаружения, траектории планируемых залпов оружия и т.д.
Модель должна поддерживать такие системные интерфейсы, как сохранение истории и трасса движения.
Для специализированных программ разбора проведенной тренировки могут потребоваться специфические данные, которые, возможно, и не нужны на момент проведения самой тренировки. Например, для установления результатов стрельбы потребуются данные от самых различных систем активного объекта: наблюденные данные по цели, рассчитанные траектории залпа и т.д. Все необходимые данные модель активного объекта должна сохранять и выдавать через интерфейс истории и событийный сервис ВМК.
До сих пор активный объект рассматривался как единая неделимая единица. Однако подводная лодка состоит из взаимосвязанных систем, которые можно представить в виде иерархической структуры моделей. Модель активного объекта подводная лодка включает в себя модели отдельных подсистем. Для каждой подсистемы необходимо разработать собственную модель. Модели взаимодействуют друг с другом через предоставляемые интерфейсы. Такое разделение незна-
Сервер Клиент ВМК
Сервер модели активной подводной лодки
Клиент модели активного ГАК
АРМО ГАК
Клиент ВМК
Клиент модели активной подводной лодки
Сервер модели активного ГАК
Рис. 2
чительно увеличивает объем работ, однако дает большие преимущества. Как правило, к адекватности моделирования активного объекта предъявляются более высокие требования по сравнению с моделированием пассивного объекта. Повышение адекватности моделирования требует большей производительности вычислительных ресурсов. Благодаря разделению крупных моделей на более мелкие их серверы могут располагаться на от-
дельных узлах сети. На рисунке 2 показано отделение модели активного гидроакустического комплекса (ГАК) от модели активного объекта подводной лодки. Естественно, модель подводной лодки не содержит в себе никакой реализации имитатора ГАК.
Разделение на отдельные модели дает дополнительную гибкость в написании более крупных обобщающих моделей. Появляется возможность модификации моделей отдельных систем без изменения других компонентов.
Соединение двух и более тренажных комплексов, разработанных по рассмотренной технологии, не будет требовать никаких затрат, при этом возможно адекватное моделирование самых различных объектов.
Список литературы
1. Башмаков А.И., Башмаков И.А. Разработка компьютерных учебников и обучающих программ. - М.: Филинъ, 2003.
2. Бичаев Б.П. Морские тренажеры (Структуры, модели, обучение). - Л.: Судостроение, 1986. - 383 с.
АРМО 1
АРМО N
ОПТИМИЗИРУЮЩИЕ СТРАТЕГИИ ВИЗУАЛИЗАЦИИ ДАННЫХ В ТАКТИЧЕСКОМ ТРЕНАЖЕРЕ
И.В. Новиков; А.И. Егоров (НИИ «Центрпрограммсистем», г. Тверь, [email protected])
Ключевые слова: тактический тренажер, визуализация данных,
В современном тактическом тренажере одним из основных компонентов является пост руководства обучением (ПРО). Помимо основополагающих функций, ПРО выполняет задачи визуализации результатов имитационного процесса. При проектировании подобного рода компонентов возникают проблемы, связанные с пошаговым моделированием имитационного процесса, в частности, с временными затратами на визуализацию, которые не должны превышать шаг моделирования (дискретизации). Как следствие, возникает необходимость создания единой системы визуализации данных, учитывающей аспекты дискретизации.
Для эффективной визуализации ПРО в НИИ «Центрпрограммсистем» (г. Тверь) разрабатывается компонентно-ориентированная библиотека пользовательского интерфейса - IML UI (Interface modeling library for User Interface).
В концепции компонентной модели ПРО каждый моделируемый объект тактической обстановки может предоставлять пользовательский интерфейс, который характеризуется множеством элементов управления (ЭУ). Каждый ЭУ в IML UI определяется набором атрибутов (позиция, имя, идентификатор, текст, пользовательские данные) и совершаемых над ним операций. ЭУ образуют
льзовательский интерфейс, паттерн «стратегия».
иерархию (дерево): каждый ЭУ создается в некотором другом элементе, называемом родительским. Взаимодействие между моделями тактического тренажера и ЭУ осуществляется путем последовательного выполнения предопределенных операций. Множество таких операций выполняются синхронно в каждый момент с определенным шагом. Эффективная реализация этих операций может существенно повысить производительность ПРО.
Рассмотрим основные операции, производимые над ЭУ, то есть определим интерфейс взаимодействия. Помимо базовых операций (получение интерфейсов, модификация основных атрибутов), введем дополнительные, список которых вместе с соответствующим методом программного интерфейса выглядит следующим образом:
1) вычисление (оценка) размера ЭУ - Esti-mateSize;
2) обновление расположения дочерних элементов - UpdateLayout;
3) обновление части экрана (прямоугольника) - InvalidateCtrl;
4) рисование ЭУ на физическом устройстве -DoPaint;
5) поиск в дереве ЭУ по заданным значениям атрибутов - ГМСоп^о1.
