Распределённая имитация с высокоуровневой архитектурой (HLA)

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

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

Архитектура HLA является следствием рамочного подхода и определяется тремя основными элементами:

- Правилами, которые управляют поведением всей распределённой имитации (федерацией) и её членами (федератами);

- Спецификацией интерфейса, которая устанавливает интерфейс между каждым федератом и исполняемой инфраструктурой. Этот интерфейс обеспечивает услуги связи и согласования для федератов;

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

В имитации архитектура HLA играет роль подобную CORBA, COM+, и т.п. в объектно-ориентированной программной разработке.

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

C++. Такой подход к разработке федерации мог бы сократить время и стоимость разработки имитации, и избежать многих ошибок на ранних стадиях процесса разработки.

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

Но если мы хотим построить федерат с AnyLogic, который отрегулирован и/или ограничен по времени, мы должны будем видоизменить аппаратную модель, чтобы разрешить упреждения, согласованные по времени, всем участникам распределённой имитации. Наиболее общий способ достигнуть такого согласования – это использовать нулевое упреждённое значение (для федератов, регулируемых по времени), и вызвать услугу управления временем Next Event Request Available (доступен запрос следующего события) (NERA).

Услуга NERA(t) даёт возможность осуществить доставку всех запрашиваемых RO-сообщений, гарантирует упреждение времени по отношению ко времени t (если больше не будет передано TSO-сообщений (сообщений с возможностью работы с разделением времени) с отметкой времени менее чем t), или по отношению ко времени tl < t, где tl — это самая низкая отметка времени всех заданных TSO-сообщений. Затем, она доставляет это TSO-сообщение федерату.

Использование вызова услуги NERA даёт возможность отправлять и/или получать дополнительные TSO-сообщения, заданные в реальное время, и позволяет осуществлять бесшовную стыковку локальных аппаратных моделей AnyLogic и HLA.

Моделирующие модели часто подразделяются на две группы: открытые и закрытые модели.

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

Закрытые модели не предусматривают применение такого интерфейса. Процесс прогона модели скрыт кодом пользователя.

AnyLogic представляет закрытую систему на протяжении длительного времени. Для пользователя не предусмотрен интерфейс для контроля процесса прогона модели. При интегрировании HLA-модуля мы сталкиваемся с проблемой отсутствия такого интерфейса, который мог бы обеспечить пользователя возможностью синхронизировать модельное время с глобальным таймером — время, в течение которого происходит объединение (федерация).

Мы разработали универсальный интерфейс, которым может пользоваться любой пользователь внешнего модуля, например, с помощью модуля компоновать какой-то объект реального окружения с моделью AnyLogic. Этот интерфейс используется в частности модулем поддержки высокоуровневой архитектуры HLA, который объединяет AnyLogic и федерацию высокоуровневой архитектуры. Этот интерфейс называется StepHook.

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

StepHook-интерфейс позволяет пользователю поставить ловушку механизму, выполняющему такты модели. Специальный метод Engine.setStepHook(com.xj.anylogic.StepHooK) используется для установки ловушки для такта.

StepHook-интерфейс включает два метода:

1. ускоренный nextEvent (ускоренное время)

Механизм прибегает к использованию этого метода как раз перед каждым тактом. Единственный параметр метода — это время, когда планируется следующее событие. Оно может быть ускоренным. ПОЛОЖИТЕЛЬНАЯ БЕСКОНЕЧНОСТЬ, если нет запланированных событий. Внедрение метода может вернуть ещё один момент времени, который должен наступить не позднее, чем момент time, поэтому системные часы будут настроены только на этот момент времени (на графике).

2. свободный timeStepDoneQ

Механизм вызывает этот метод сразу после того, как системные часы настроены на время, полученное от nextEventQ.

Для облегчения взаимодействия во время федерации, специальный компонент – часть модели AnyLogic – должен передавать по маршруту сообщения и синхронизировать локальные системные часы с глобальным временем федерации. Такой компонент разработан. В настоящее время ядро ОС AnyLogic взаимодействует с исполняемой инфраструктурой через модуль HLA. Описанный выше StepHook-интерфейс используется как интерфейс взаимодействия между модулем поддержки высокоуровневой архитектуры и механизмом модели AnyLogic.

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

1. Управление федерацией (FM)

• Создать/объединить/подчинить/разрушить исполнение объединения

• Точки синхронизации, распространённые по всей федерации

2. Управление объявлением (DM)

• Публикация/подписка объектного класса

• Публикация/подписка классов взаимодействия

• Предупреждения объявлениям

3. Управление объектом (OM)

• Регистрация/обнаружение/удаление экземпляров класса объектов

• Отправка/получение взаимодействий

• Обновление/отображение атрибутов

• Предупреждения объявлениям

4. Управление временем (ТM)

• Опережение времени

• Регулировочные/ограничительные переключатели

• Запросы и элементы управления, связанные со временем

Интеграция высокоуровневой архитектуры в AnyLogic требует должного внимания. Наибольшие затруднения возникают в распределённой имитации вследствие гибридного происхождения имитационных компонентов системы.

Условия обнаружения, определяемые по непрерывно изменяющимся переменным интерфейса.

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

В гибридной системе есть два основных возможных соединения между взаимодействующими объектами.

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

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

Итоговый объем информации необходимо передать как предикату, так и послать сообщение по сети.

Можно порекомендовать разрабатывать распределённую имитацию таким образом, чтобы компоненты «инкапсулировали» свой режим работы, показывая непрерывные функции времени (атрибуты) только для нужд информирования о ситуации, визуализации и сбора отдалённой статистики при сравнительно низкой скорости. Обнаружение всех необходимых событий, идентифицированных во время создания имитации (федерации) и её разработки, затем выполняются внутри компонента, и соответствующее уведомление посылается всем необходимым компонентам.

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

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

Применимость оценки отдалённого предиката к модели двух колебательных контуров.

Более поздний метод был осуществлён с прототипом поддержки высокоуровневой архитектуры, который является добавочным к модели «AnyLogic» для распределённой имитации задачи двух колебательных контуров, о которой говорилось выше. Контроллер отслеживает значение h2, и когда оно достигает опасно высокого уровня L+, контроллер подаёт команду открыть соответствующий клапан.

Иными словами, компонент контроллера определяет предикат на непрерывной переменной h2 в форме h2 > L+. С тех пор, как h2 моделируется в другом компоненте, метод обновления h2 может прямо влиять на время задержки перед тем, как подать команду открыть клапан, и таким образом может привести к переполнению 2 контура (это – как раз то, что мы наблюдаем, используя выборку во время распределённой имитации). Та же самая система, имитируемая как отдельная модель AnyLogic, не показывает такого переполнения. На этом примере мы можем видеть, что распределённая имитация гибридной системы может показывать неверные результаты просто по причине непрерывной задержки обновления переменной.

Решение данного вопроса заключается в разрешении федерату контроллера определить значение L+ для федерата двух колебательных контуров.

Мы сделали это, определив взаимодействие (обмен данными) высокоуровневой архитектуры с параметром, определяющим значение L+. После приёма данных федерат двух колебательных контуров изменяет параметр предиката на h2 (h2 > L+) и оценивает его во время решения системы дифференциальных уравнений. После того, как предикат становится верным (событие обнаружено), федерат обновляет значения для h1 и h2 а контроллер обнаруживает это событие с минимальной возможной ошибкой. Поскольку предикат оценивается «отдалённо» федератом, имитирующим непрерывную функцию времени, мы называем этот метод Оценка отдалённого предиката.

Этот метод показывает возможность решать рассматриваемую проблему для данного специфического примера распределённой имитации.

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

Использование высокоуровневой архитектуры для передачи кода агента оценки отдалённого предиката.

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

Это решение связано только с функциями исполняемой инфраструктуры, не только с некоторым особым протоколом. Таким образом, мы не ограничиваем каким-либо образом пространственную среду.

Это особое взаимодействие (взаимодействие с оценкой отдалённого предиката) должно быть описано в трафарете модели объекта федерации.

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

По получении взаимодействия (данных) с оценкой отдалённого предиката (с кодом агента внутри), модуль поддержки высокоуровневой архитектуры не передаёт её в механизм модели «Any-Logic», он передаёт такое взаимодействие в специальный модуль оценки отдалённого предиката.

Для поддержки агента отдалённого предиката разрабатывается специальный загрузочный модуль. Мы назвали этот модуль – модуль оценки отдалённого предиката. Этот модуль взаимодействует и с механизмом модели «AnyLogic», и с модулем поддержки высокоуровневой архитектуры.

Процесс загрузки предиката описан ниже.

1. Код предиката после передачи через сеть передаётся исполняемой инфраструктурой в модуль поддержки высокоуровневой архитектуры как взаимодействие особого типа. Этот особый тип взаимодействия служит в качестве контейнера для кода предиката.

2. Модуль поддержки высокоуровневой архитектуры определяет тип взаимодействия. Если этот тип взаимодействия совпадает с взаимодействием оценки определённого предиката, модуль поддержки высокоуровневой архитектуры не передаёт его в модель «AnyLogic», а передаёт модулю оценки определённого предиката.

3. Модуль оценки определённого предиката загружает передаваемый класс в предписанный вектор отдалённых предикатов.

Каждый шаг модели в векторе предиката оценивают все предикаты. Модуль оценки отдалённого предиката анализирует каждое состояние предиката. Если любой предикат инициирует свои состояния, модуль оценки отдалённого предиката генерирует локальное событие, которое контролируется механизмом «AnyLogic».

Такое событие ассоциируется с механизмом, который отражает все свойства моделей в федерацию.

Предлагаемое решение развивается, в конечном счёте, быстро. Нет необходимости в последовательном разборе при проверке запуска предиката. Решение использует предварительно скомпилированный код Ява.

Нет необходимости в перекомпиляции при загрузке агента. Агенты предварительно скомпилированы на отдалённых федератах.

Агенты могут быть загружены и разгружены динамически.

Не применяются ограничения к отдалённо загруженному предикату. Пользователь может записать почти весь код. Агент может представлять предикат любой сложности. Например, агент может сохранять и анализировать историю режима работы федерата, в который он был загружен.

Агенты могут быть параметризированы. Какой-либо отдалённый федерат может послать агент на локальный федерат, выждать некоторое время, разгрузить его и снова послать агент с другими параметрами.

Первое ограничение, которое должно применяться к коду агента, заключается в том, что удалённо загруженный агент должен быть последующим элементом какого-то абстрактного класса. Отдалённо загруженный агент должен представлять предопределённый интерфейс для взаимодействия с модулем вычислителя отдалённого предиката.

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

Заключение

Гибридный подход к конечным автоматам, реализуемый в моделировании «AnyLogic» и имитировании окружающей среды является мощной и удобной формальной системой для описания режима работы систем реального окружения. Сама модель «AnyLogic» представляет собой очень гибкое инструментальное средство, которое, по существу, является окружением для программирования на Ява с поддержкой визуальной спецификации смоделированной системы в терминах моделирования библиотеки классов. Это свойство «AnyLogic» делает сравнительно лёгким разработку расширения поддержки высокоуровневой архитектуры и позволяет активировать компоненты, созданные с помощью инструментального средства, участвующего в распределённых имитациях.

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

Была предложена интеграция техники оценки отдалённого предиката и стандарта высокоуровневой архитектуры. Конечно, разработанные техники оценки отдалённого предиката представляют некоторые сверхструктуры на стандарте высокоуровневой архитектуры. И более того, текущая технология ограничена федератами Ява, поскольку код агента оценки определённого предиката, будучи переданным инфраструктурой времени прогона как взаимодействие, представляет серийный Ява-объект. Однако, существует много возможностей усовершенствовать технику оценки отдалённого предиката, и мы продолжаем над этим работать.