Прикладные модули модели воздушного судна

Заменитель

Заменителями называются приложения, реализующие тактику «введение посред­ника». Они ответственны за межсистемный обмен данными — конкретнее, меж­ду моделью воздушного судна, с одной стороны, и моделью окружающей среды или операторской станцией — с другой. Располагая информацией о физических характеристиках систем, с которыми они взаимодействуют, заменители обеспе­чивают представление, предоставляют протокол передачи данных и т. д.

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

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

Типы модулей прикладного субэлемента структурной модели воздушного судна показаны на рис. 8.5. Собственно, их всего два: контроллер подсистемы (subsystem controller) и дочерний модуль контроллера (controller child). Контроллеры подси­стем передают данные от других и другим экземплярам контроллеров подсистем, их дочерним модулям. Дочерние модули контроллеров передают данные, между собой и своими родителями; с другими дочерними модулями они взаимодействуют. Управление они получают только от родителей и возвращают его им же. Эти ограничения запрещают дочерним модулям передавать данные ¹⁰управление даже своим братьям. Запрет на сцепление дочерних экземпляров с кем-либо иным, кроме своих родительских элементов логически обосновывается задачами по достижению интегрируемости и модифицируемости.

В роли посредника при воздействии модификаций и интеграции всегда выступает родительский контроллер подсистемы. Все это согласуется с тактикой «ограничение обмена данными».

Контроллер подсистемы

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

♦ моделирование подсистемы в целом;

♦ посредничество в обмене данными управления и непериодическом обмене между системой и подсистемами.

Кроме того, они ориентируют дочерние модули на реализацию тренировоч­ной функциональности — в частности, моделирование неисправностей и уста­новку параметров.

Поскольку образец «структурная модель» ограничивает обмен данными меж­ду дочерними модулями контроллера, контроллеру подсистемы приходится ус­танавливать между ними самими, с одной стороны, и между ними и другими подсистемами — с другой, логические соединения. Входящие соединения удов­летворяют аналогичные потребности сторонних подсистем и заменителей. Эти соединения представляют собой наборы имен, посредством которых контролле­ры подсистем осуществляют внутренние обращения к внешним данным. Допу­щения об установлении соединений принимаются при считывании или записи таких имен. Механизм фактического установления соединений определяется поз­же, на стадии детального проектирования, и выражается в изменяемом парамет­ре образца (изменяемые параметры рассматриваются в главе 14 «Линейки про­дуктов»). Помимо установления соединений между собственными дочерними модулями и дочерними модулями других подсистем контроллер подсистемы ис­полняет роль посредника во взаимодействии между своими дочерними модуля­ми - дело в том, что ограничение средств связи между ними предполагает запрет ^На прямой обмен данными.

Как мы уже говорили, система моделирования условий полета может нахо­диться в нескольких состояниях. Посредством организующей части она перево­дится в конкретное состояние исполнения. После этого организующая часть со- °6щает контроллеру подсистемы о текущем состоянии. Для нас значимыми ^Являются состояния «Работа» (operate) и «Стабилизация» (stabilize). В состоя­нии работы контроллер подсистемы выполняет нормальные вычисления, сиособ- ^f дующие продвижеиию состояния моделирования. В состоянии стабилизации ^к'^жтроллер подсистемы управляемым образом завершает текущие вычисления (при неконтролируемом завершении спорадические движения платформы могут повредить экипажу). Последовательность действий при этом выглядит так:

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

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

Контроллеры подсистем должны выполнять следующие действия.

♦ В ответ на любое событие инициализировать себя и все свои дочерние модули набором начальных условий.

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

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

Контроллеры подсистем должны предоставлять две периодические операции - update и import — и могут поддерживать две другие (непериодические): process_event и configure.

Update

Операция update заставляет контроллер подсистемы проводить периодическую обработку согласно текущему рабочему состоянию, которое предоставляется в ка­честве входного параметра. В состоянии operate операция update заставляет кон­троллер подсистемы:

1) устанавливать входные соединения и извлекать для дочерних модулей вход­ные данные;

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

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

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

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

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

♦ import. Операция import заставляет контроллер подсистемы завершать не­которые входные соединения — считывать их значения и проводить их локальное сохранение в расчете на последующее применение операцией update.

Контроллеры подсистем предоставляют две непериодические операции: process event и configure.

♦ process, event. Операция process_event применяется в преимущественно пе­риодических рабочих состояниях (к числу которых, в частности, относится состояние operate) для вызова реакции контроллера подсистемы на собы­тие, предоставляемое в виде входного параметра. Под эту категорию подпа­дает ряд событии операторской станции: process_malfunction, set_parameter л hold_parameter.

♦ configure. Операция configure применяется в таких преимущественно непе­риодических состояниях системы, как initialize. Она предназначена для ус­тановления именованного набора условий — например, конфигурации учеб­ного устройства или тренировочного задания. Информация, необходимая контроллеру подсистемы для установления такого состояния, может предо­ставляться в виде входного параметра, ячейки памяти вторичного запоми­нающего устройства или извлекаться из базы данных. Контроллер подсис­темы вызывает такие операции своих дочерних модулей, которые приводят к установлению требуемых состояний.

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