Дочерние модули контроллера

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

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

♦ предыдущего состояния;

♦ входных данных, представляющих соединения с логически смежными до­черними модулями;

♦ истекшего временного интервала.

Определение состояния проводится дочерним модулем по требованию контроллера подсистемы; он предоставляет все необходимые входные данные и извлекает данные выходные. Эта возможность называется обновлением (updating).

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

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

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

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

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

♦ Периодическое распространение среди дочерних модулей изменений со­стояния, осуществляемое через их операции update.

♦ Установление между дочерними модулями логических соединений при помощи входных и выходных параметров этих операций.

♦ Установление между логическим модулями, с одной стороны, и всеми ос­тальными элементами модели — с другой, логических соединений с при­влечением входящих и исходящих соединений подсистемы.

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

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