Рабочие состояния

Применение моделей

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

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

Система моделирования условий полета может находиться в нескольких состояниях.

♦ «Работа» (Operate) соответствует нормальному режиму функционирования системы моделирования в роли тренажера.

♦ «Настройка» (Configure) применяется при необходимости внесения в текущий учебный сеанс каких-либо изменений. К примеру, если инструктор собирается перейти от одиночного пилотажного упражнения на модель дозаправки в воздухе, он переводит систему в состояние настройки.

♦ «Остановка» (Halt) прекращает текущий сеанс моделирования.

♦ «Воспроизведение» (Replay) применяется для просмотра зафиксированных в журнале смоделированных ситуаций без взаимодействия с экипажем. Помимо прочего, этот режим используется для демонстрации экипажу записи выполненных им действий — в тех, к примеру, случаях, когда экипаж, столкнувшись с трудностями в управлении бортом, перестает реагировать на прочие факторы. В главе 5 («Реализация атрибутов качества») мы представили тактику тестирования «запись/воспроизведение». Здесь она используется в процессе тренировки.

Рассматриваемые в этой главе системы моделирования обладают следующими четырьмя свойствами:

1. Ограничения по функционированию в реальном времени. Частота смены кадров в системах моделирования условий полета должна соответствовать требованиям по точности. Объяснить, что такое «частота смены кадров», проще всего по аналогии с кинофильмами. Кадр - это снимок, фиксирующий тот или иной момент времени. Определенное количество кадров, сделанных последовательно в течение заданного периода времени, создает У наблюдателя впечатление непрерывного движения. В зависимости от условий восприятия устанавливаются разные значения частоты смены кадров. Системы моделирования условий полета, как правило, работают на частотах 30 или 60 Гц (при которых обновление производится 30 и 60 раз в секунду, соответственно). Все вычислительные операции при этом должны завершаться в пределах времени, отведенного на один кадр.

Частота любого элемента системы моделирования должна быть кратна базовой частоте (причем коффициент кратности должен быть целым). Если, к примеру, базовая частота равняется 60 Гц, то более медленные элементы системы должны работать на частоте 30, 20, 15, 12, 10, 6, 5, 4, 3, 2 или 1 Гц. Нецелочисленных коэффициентов, приводящих к значениям наподобие 25 Гц, быть, таким образом, не должно. Причина этого ограничения кроется в необходимости жесткого согласования входных сигналов от датчиков.

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

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

3. Масштабность и сложность. Для моделирования самых простых учебных ситуаций в пилотажных тренажерах, как правило, требуется ввод десятков тысяч строк кода. В сложных тренажерах совместной подготовки объем исчисляется миллионами строк. За последние 30 лет сложность систем моделирования условий полета увеличивалась экспоненциально.

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

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

1. Крайне высокая стоимость отладки, тестирования и модифицирования. Среди факторов, из-за которых стоимость тестирования, интеграции и модификации систем моделирования условий полета превышает стоимость разработки, — сложность этих программных продуктов, необходимость

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

Одним из последствий усложнения систем стало удорожание интеграции. К примеру, интеграция одной из крупных систем ВВС (объем кода в которой составил 1,7 млн строк) обошлась заказчику значительно дороже суммы, прописанной в бюджете. На очереди в тот момент были системы, объем которых должен был в 1,5 раза превысить этот показатель, и стоимость их изготовления казалась совершенно неподъемной. Так интегрируемость вышла на первый план среди всех архитектурных мотивов.

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

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

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

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

Дата добавления: 2015-04-25