Программные продукты и системы

Разработка современных обучающих программно-аппаратных тренажеров и комплексов, предназначенных для подготовки персонала, подразумевает решение ряда технических проблем. В структуре тренажера конструктивно присутствует множество составных частей, при этом каждая из них решает свои задачи. Одна из основных технических задач, возникающих в процессе разработки современных тренажеров и программно-аппарат­ных тренажерных комплексов, – это обеспечение взаимодействия программных компонентов составных частей и объединение их в общее математическое информационное пространство [1].

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

Специально под задачи космического тренажеростроения была разработана программная система распределенного моделирования ТРИО (тренажная распределенная исполнительная оболочка) [2]. Согласно этой системе, тренажер состоит из двух частей: системы моделирования, представляющей собой программную реализацию моделей узлов, и вычислительной системы, на которой осуществляется моделирование. Система ТРИО разделена на две части: среду разработки и среду исполнения. Среда разработки предназначена для автоматизированной разработки ПО системы моделирования тренажера. ТРИО объединяет в одну систему программные объекты, которые делятся на модели и форматы. Структура ПО нескольких узлов вычислительной системы при использовании технологии ТРИО показана на рисунке 1. При организации процесса моделирования среда исполнения ТРИО манипулирует всей совокупностью моделей и форматов с учетом их размещения на физически разных узлах вычислительной системы тренажера. После запуска процесса моделирования на каждом такте происходит обмен переменными между узлами в соответствии с построенными списками. Анализ существующих внедрений в комплексные тренажеры (см. рис. 1) позволяет сделать вывод о ряде существенных недостатков.

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

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

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

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

Еще одним вариантом решения задачи организации распределенного взаимодействия в сложном тренажерном комплексе является использование распределенной сетевой среды моделирования СОТА. Это комплекс взаимодействующих программных компонент, основанных на системе с объектно-ориентированной динамической БД с событийно-уведомительным управлением. Основное назначение среды СОТА – использование при разработке обучающих систем и программно-ап­паратных моделирующих комплексов в тренажеростроении в качестве базового системообразующего ПО, объединяющего программные компоненты составных частей в единое информационное пространство.

Основные возможности СОТА: хранение моделируемых данных во внутренней динамической распределенной БД, доступ к моделируемым данным, модификация моделируемых данных, автоматическая синхронизация моделируемых данных, функции конфигурирования тренажера, обработка событий и уведомлений об изменении состояний системы и объектов БД, межсетевое программное событийное взаимодействие между узлами распределенной среды моделирования, функции контроля экранов узлов СОТА и удаленного управления компьютерами.

С технической точки зрения среда моделирования СОТА является комплексом взаимодействующих программных компонент, определяющих возможности системы и решающих задачи объединения и взаимодействия составных частей тренажера. Архитектура среды моделирования СОТА представлена на рисунке 3.

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

Клиентом системы моделирования СОТА является приложение Windows, к которому подключен программный модуль и в исходный код которого встроен программный интерфейс взаимодействия СОТА (рис. 5). Другое название клиента – узел СОТА. Клиент определяет каркас програм- много компонента среды моделирования. Все узлы среды взаимодействуют между собой, используя сетевой протокол TCP-IP. Несколько клиентов СОТА могут быть запущены на одной рабочей станции (персональном компьютере) или сервере либо могут быть распределены по сети Ethernet и запускаться на разных рабочих станциях. В обоих случаях ядро системы моделирования СОТА обеспечит сетевое информационное взаимодействие и автоматически выполнит синхронизацию данных между клиентами.

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

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

Менеджер процессов системы моделирования СОТА – программный интерфейс, обеспечивающий удаленный запуск на рабочих станциях клиентов СОТА и различных приложений Windows и контроль за их состоянием (запущен/выгружен) с возможностью удаленного корректного завершения запущенных процессов. Основное назначение менеджера процессов – использование в качестве центра системы конфигурирования и реконфигурирования состояний сложных тренажеров и программно-аппаратных тренажерных комплексов, состоящих из множества компонентов, объединенных в локальную вычислительную сеть.

Каждый клиент СОТА, присоединенный к среде моделирования, проходит через несколько этапов: регистрацию, подключение, верификацию данных, процесс моделирования, отключение по завершении работы. Этап регистрации заключается в присоединении к программному модулю регистрации и в получении списка портов и IP-адресов зарегистрированных клиентов СОТА. Система верификации обеспечивает проверку целостности данных при подключении клиентов СОТА к среде моделирования. Сетевой транспорт среды моделирования СОТА построен на базе протоколов ТСP-IP и реализован на базе сокетов Windows, работающих в асинхронном режиме. После регистрации и успешной верификации устанавливается постоянное сетевое соединение между узлами для передачи данных. Каждому сетевому соединению по протоколу TCP-IP соответствует отдельный поток операционной системы Windows. Данные между узлами передаются посредством сообщений. Среда моделирования СОТА может создавать между узлами дополнительные каналы сетевого взаимодействия, предназначенные для параллельной передачи больших объемов информации между клиентами СОТА.

БД типов системы моделирования СОТА – это совокупность описаний типов данных на языке программирования С++. За каждым типом данных закреплен свой уникальный идентификатор и привязан определенный GUID [4]. Каждый тип данных привязан к определенному узлу-хозяину или плагину (формату)-хозяину, при этом только исходный код программного модуля хозяина имеет право создавать, удалять и модифицировать объекты своего типа данных. Объекты типов данных создаются, модифицируются и уничтожаются по мере необходимости в процессе работы системы моделирования. При отсутствии объектов на текущем узле система моделирования СОТА автоматически выполнит проецирование необходимых данных на текущий узел. Каждый клиент и плагин системы моделирования СОТА имеют в своем составе программный интерфейс, обеспечивающий обработку событий. Посредством обработчика событий в среде моделирования СОТА реализуется программное взаимодействие между клиентами, плагинами и форматами. Ответной реакцией среды моделирования СОТА на внешние и внутренние воздействия являются уведомительные со- бытия и события-команды. При компиляции программного ядра среды моделирования СОТА автоматически формируется программный инструментарий разработчика SOTA SDK. Наличие программного инструментария облегчает автоматизацию процесса проектирования и разработки ПО тренажерных комплексов.

Особенности реализации ПО среды моделирования СОТА:

–      легкость доступа: доступ к объектам БД СОТА, а также к программным интерфейсам СОТА можно получить практически из любого cpp- или h-файла;

–      автоматическая сборка мусора: при завершении работы среда моделирования корректно автоматически выгружает все объекты БД СОТА и освобождает занимаемую память;

–      корректное закрытие сетевых соединений: при завершении работы клиенты среды моделирования СОТА отрабатывают все необработанные входящие сетевые сообщения и отсылают все накопленные исходящие, после чего корректно закрывают сетевые подключения;

–      независимость расположения: плагины СОТА не привязаны жестко к определенному узлу и могут менять узел по необходимости без потери работоспособности, в то же время клиенты СОТА жестко не привязаны к IP-адресам рабочих станций и при необходимости могут изменить свое местоположение в ЛВС без потери работоспособности системы моделирования.

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

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

Создание тренажерных комплексов с использованием среды моделирования СОТА можно разделить на следующие этапы.

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

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

3.     Занесение разработанных структур типов данных в БД СОТА и проектирование дополнительных возможностей (конфигурирование, наблюдение) в рамках разрабатываемого тренажера.

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

Литература

1.     Шукшунов В.Е., Янюшкин В.В. Проектирование тренажерно-моделирующих комплексов нового поколения // Программные продукты и системы. 2012. № 4. С. 192–200.

2.     Шукшунов В.Е., Циблиев В.В., Потоцкий С.И. Тренажерные комплексы и тренажеры. Технологии разработки и опыт эксплуатации. М.: Машиностроение, 2005. 384 с.

3.     Шорин А.Б., Новиков И.В. Варианты взаимодействия рабочих мест тактического тренажера // Программные продукты и системы. 2009. № 1. С. 111–113.

4.     Рихтер Д., Назарр К. Windows via C/C++. Программирование на языке Visual C++. СПб: Питер, Русская редакция, 2009. 896 с.

References

1.     Shukshunov V.E., Yanyushkin V.V., Programmnye pro­dukty i sistemy [Software and Systems], 2012, no. 4, pp. 192–200.

2.     Shukshunov V.E., Tsibliev V.V., Pototsky S.I., Trena­zhernye kompleksy i trenazhery. Tekhnologii razrabotki i opyt ekspluatatsii [Training complexes and simulators. Design technique and field experience], Moscow, Mashinostroenie, 2005.

3.     Shorin A.B., Novikov I.V., Programmnye produkty i sis­temy [Software and Systems], 2009, no.1, pp. 111–113.

4.     Richter J., Nazarre Ch., Windows via C/C++. Programmi­rovanie na yazyke Visual C++ [Windows via C/C++. Visual C++ programming], Piter, 2009.