Архитектура высокого уровня - High Level Architecture

Эта статья посвящена стандарту IEEE для распределенного моделирования. Для использования в других целях см. Высокий и низкий уровень.

В Архитектура высокого уровня (HLA) является стандартом для распределенного моделирования, который используется при построении моделирования для более широкой цели путем объединения (объединения) нескольких симуляций.[1] Стандарт был разработан в 90-х годах под руководством Министерства обороны США.[2] и позже был преобразован в открытый международный стандарт IEEE. Это рекомендуемый стандарт в НАТО через СТАНАГ 4603.[3] Сегодня HLA используется во многих областях, включая оборону и безопасность, а также гражданские приложения.

Цель HLA - обеспечить возможность взаимодействия и повторного использования. Ключевые свойства HLA:

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

HLA формирует основу для разработки стандартизированных и расширяемых FOM в различных сообществах, например, в аэрокосмической и оборонной сферах.

В архитектуре определены следующие компоненты.

Компоненты федерации HLA
  • А Инфраструктура времени выполнения (RTI), который предоставляет стандартизованный набор услуг на разных языках программирования. Эти услуги включают обмен информацией, синхронизацию и управление федерацией.
  • Федерации которые представляют собой индивидуальные системы моделирования, использующие сервисы RTI.
  • А Объектная модель федерации (FOM), который определяет классы объектов и классы взаимодействия, используемые для обмена данными. FOM может описывать информацию для любого домена.

Вместе вышеуказанные компоненты образуют Федерация.

Стандарт HLA состоит из трех частей:

  1. Структура и правила IEEE Std 1516-2010,[4] который определяет десять архитектурных правил, которых должны придерживаться компоненты или вся федерация.
  2. Спецификация федеративного интерфейса IEEE Std 1516.1-2010,[5] который определяет услуги, которые должны быть предоставлены RTI. Услуги предоставляются как C ++ и Java API, а также как веб-службы.
  3. Спецификация шаблона объектной модели IEEE Std 1516.2-2010,[6] который определяет формат, который должны использовать объектные модели HLA, такие как FOM.

История и версии

HLA была инициирована в начале 1990-х годов, когда Dr. Анита К. Джонс, директор отдела оборонных исследований и разработок Министерства обороны США, поручил Управлению оборонного моделирования и моделирования (DMSO) «обеспечить совместимость и возможность многократного использования оборонных моделей и симуляторов».[1] В 1995 году DMSO сформулировал концепцию моделирования и моделирования и разработал генеральный план моделирования и моделирования, который включал в себя архитектуру высокого уровня.

Уже существуют два протокола для взаимодействия M&S: Распределенное интерактивное моделирование (DIS), уделяя особое внимание моделированию уровня платформы в реальном времени с фиксированной объектной моделью, и Протокол моделирования агрегированного уровня (ALSP) с упором на моделирование агрегата с управлением временем, управлением владением и гибкими объектными моделями, называемыми моделями конфедерации. Целью HLA было предоставить единый стандарт, который отвечал бы требованиям совместимости моделирования для всех компонентов Министерства обороны США.[2]

Разработка HLA была основана на четырех прототипных федерациях: Федерация прототипов платформ, Объединенное обучение прототипов, Аналитическое прототипирование и Инженерная федерация прототипов. Спецификация HLA была прототипирована и уточнена, пока наконец не был выпущен HLA 1.3. Чтобы облегчить использование за пределами оборонного сообщества, HLA был затем переведен в стандарт IEEE, поддерживаемый Организация по стандартам совместимости моделирования (SISO). Чтобы облегчить миграцию для пользователей DIS, объектная модель федерации, соответствующая фиксированной объектной модели DIS, также была разработана как Справочник по платформе реального времени FOM (РПР ФОМ ).

Существуют следующие версии HLA:

HLA 1.3

HLA 1.3 был опубликован DMSO в марте 1998 года. Это состоит из:

  • Министерство обороны США, версия правил 1.3
  • Министерство обороны США, Спецификация интерфейса архитектуры высокого уровня, версия 1.3
  • Министерство обороны США, шаблон объектной модели архитектуры высокого уровня, версия 1.3

Министерство обороны США также опубликовало интерпретацию HLA 1.3:

  • Министерство обороны США, Интерпретации спецификации интерфейса архитектуры высокого уровня, версия 1.3, выпуск 3

HLA 1516-2000

HLA IEEE 1516-2000 был опубликован в 2000 году IEEE. Это состоит из:

  • IEEE Std 1516–2000 - Стандарт для моделирования и симуляции архитектуры высокого уровня - Структура и правила
  • IEEE Std 1516.1–2000 - Стандарт для моделирования и симуляции архитектуры высокого уровня - Спецификация федеративного интерфейса
  • IEEE 1516.1–2000 Errata (16 октября 2003 г.)
  • IEEE 1516.2-2000 - Стандарт для моделирования и симуляции архитектуры высокого уровня - Спецификация шаблона объектной модели (OMT)

Основные улучшения в IEEE 1516-2000 включают FOM на основе XML с подробными спецификациями типов данных, а также улучшенный дизайн DDM.

Стандарт IEEE 1516-2000 также был дополнен рекомендованным процессом разработки, а также рекомендованным процессом VV&A:

  • IEEE 1516.3-2003 - Рекомендуемая практика для процесса разработки и выполнения федерацией архитектуры высокого уровня (FEDEP). Этот стандарт позже стал IEEE Std 1730-2010 Distributed Simulation Engineering and Execution Process (DSEEP )
  • IEEE 1516.4-2007 - Рекомендуемая практика для проверки, валидации и аккредитации федерации, накладывающаяся на процесс разработки и выполнения федерации архитектуры высокого уровня

Вскоре было обнаружено, что в стандарте 1516-2000 есть API, которые немного отличаются для каждой реализации RTI. SISO разработала стандарт с альтернативными API C ++ и Java, совместимыми с динамическими ссылками (DLC):

  • SISO-STD-004.1-2004: Стандарт HLA API, совместимый с Dynamic Link Стандарт для спецификации интерфейса HLA (версия IEEE 1516.1)
  • SISO-STD-004-2004: Стандарт HLA API, совместимый с Dynamic Link Стандарт для спецификации интерфейса HLA (v1.3)

Позже API DLC были объединены в основной стандарт.

HLA 1516-2010 (разработанная HLA)

Стандарт IEEE 1516-2010 был опубликован в августе 2010 года IEEE и широко известен как HLA Evolved.[7] Это состоит из:

  • IEEE 1516–2010 - Стандарт для моделирования и симуляции архитектуры высокого уровня - Структура и правила[4]
  • IEEE 1516.1–2010 - Стандарт для моделирования и симуляции архитектуры высокого уровня - Спецификация федеративного интерфейса[5]
  • IEEE 1516.2-2010 - Стандарт для моделирования и симуляции архитектуры высокого уровня - Спецификация шаблона объектной модели (OMT)[6]

Основные улучшения в IEEE 1516-2010 включают модульные FOM,[8] включение API-интерфейсов DLC в C ++ и Java, API веб-служб[9] и отказоустойчивость.[10]

Машиночитаемые части этой версии HLA, такие как схемы XML, C ++, Java и WSDL API, а также образцы FOM / SOM можно загрузить с область загрузки IEEE 1516 на веб-сайте IEEE. Полные тексты стандартов доступны бесплатно для членов SISO или могут быть приобретены в магазин IEEE.

HLA 1516-20XX (HLA 4)

Разработка новой версии HLA началась в январе 2016 года компанией SISO и продолжается в настоящее время.

Технический обзор

Стандарт HLA состоит из трех частей:

  • Рамки и правила, который определяет десять архитектурных правил, которых должна придерживаться федерация или вся федерация.
  • Спецификация федеративного интерфейса, который определяет услуги, которые должны быть предоставлены RTI. Услуги предоставляются как C ++ и Java API, а также как веб-службы.
  • Спецификация шаблона объектной модели который определяет формат, который должны использовать объектные модели HLA, такие как FOM.

Общая терминология HLA

  • Инфраструктура времени выполнения (RTI): Программное обеспечение, которое предоставляет стандартизированный набор услуг, как указано в спецификации интерфейса HLA Federate. Есть семь сервисных групп.
  • Федеративная: Система, такая как симуляция, инструмент или интерфейс к действующим системам, которая подключается к RTI. Примерами инструментов являются регистраторы данных и инструменты управления. Федерация использует службы RTI для обмена данными и синхронизации с другими федерациями.
  • Федерация: Набор федераций, которые подключаются к одному RTI вместе с общим FOM.
  • Казнь Федерации: Сеанс, в котором группа федераций выполняет совместную работу в федерации с определенной целью, используя одни и те же RTI и FOM.
  • Объектная модель федерации (FOM): Документ, определяющий классы объектов, классы взаимодействия, типы данных и дополнительные данные, которые используются для обмена информацией в федерации. FOM - это файл XML, который соответствует формату шаблона объектной модели HLA и связанной схемы XML. Различные FOM используются для обмена данными для разных доменов приложений. Существуют стандартизированные FOM, называемые эталонными FOM, которые обычно используются в качестве отправной точки для разработки FOM. FOM можно разрабатывать и расширять по модульному принципу с использованием модулей FOM.
  • Имитационная объектная модель (SOM): Документ, который определяет классы объектов, классы взаимодействия, типы данных и дополнительные данные, которые конкретное моделирование публикует и / или на которые подписывается в федерации. SOM также является XML-файлом, который следует формату шаблона объектной модели HLA и связанной схемы XML. SOM также могут разрабатываться и расширяться по модульному принципу с использованием модулей SOM.
  • Объект: Объекты используются для представления данных, которые сохраняются в течение определенного периода времени и имеют атрибуты, которые можно обновлять. Они определены в FOM / SOM с использованием класса объекта.
  • Взаимодействие: Взаимодействие используются для представления мгновенных событий с параметрами. Отправленное взаимодействие нельзя обновить (в отличие от классов объектов). Они определены в FOM / SOM с использованием класса взаимодействия.
  • Типы данных: Представление и интерпретация данных атрибутов и параметров указывается в FOM / SOM с использованием типов данных HLA.
  • Публиковать: Федерация, которая публикует класс объектов с набором атрибутов, может регистрировать и удалять экземпляры этого класса объектов и обновлять значения его атрибутов. Федерация, которая публикует класс взаимодействия, может отправлять взаимодействия этого класса взаимодействия вместе со связанными значениями параметров.
  • Подписаться: Федерация, которая подписывается на объектный класс с набором атрибутов, обнаружит регистрации и удаления экземпляров этого объектного класса и получит обновления подписанных атрибутов. Федерация, которая подписывается на класс взаимодействия, будет получать взаимодействия этого класса взаимодействия вместе со связанными значениями параметров.

Спецификация интерфейса

Услуги RTI определены в Спецификации интерфейса HLA. Они сгруппированы в семь сервисных групп. В дополнение к этим службам объектная модель управления (MOM) предоставляет службы, которые позволяют программно проверять и корректировать состояние федерации.

Большинство RTI состоят из центрального компонента RTI (CRC), который является исполняемым файлом, и локальных компонентов RTI (LRC), которые представляют собой библиотеки, используемые федерациями. Услуги предоставляются через C ++ или же Ява API, а также с использованием веб-сервисов. В API C ++ и Java службы вызываются с помощью вызовов экземпляра класса RTI Ambassador. RTI доставляет информацию федерации с помощью обратных вызовов, которые доставляются с помощью вызовов экземпляру класса Federate Ambassador. В API веб-служб, определенном с помощью WSDL, выполняются вызовы и получаются обратные вызовы федерацией с использованием запросов и ответов веб-служб.

Приведенные ниже описания групп услуг сосредоточены на ключевых услугах. Исключения и рекомендации не включены.

Службы управления федерацией

Назначение служб управления федерацией, описанное в главе 4 спецификации интерфейса HLA,[5] предназначен для управления выполнением федерации, а также общесистемными операциями, такими как точки синхронизации и сохранение / восстановление.

Один набор служб управления федерацией управляет подключением к RTI, выполнением федерации и набором объединенных федераций. Ключевые услуги:

  • Подключение и отключение от RTI
  • CreateFederationExecution и DestroyFederationExecution, которые используются для создания и уничтожения выполнения федерации.
  • JoinFederationExecution и ResignFederationExecution, которые используются федерацией для присоединения к федерации и выхода из нее.
  • ConnectionLost, который используется RTI для информирования федерации о том, что он потерял соединение с выполнением федерации из-за ошибки.
  • ListFederationExecutions, который используется для получения списка доступных исполнений федерации для RTI.

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

  • RegisterFederationSynchronizationPoint, который используется для регистрации точки синхронизации.
  • AnnounceSynchronizationPoint, который используется RTI для информирования федераций о том, что точка синхронизации была зарегистрирована.
  • SynchronizationPointAchhibited, который используется федерацией, чтобы указать, что он достиг точки синхронизации.
  • FederationSynchronized, который используется RTI для информирования федераций о том, что федерация синхронизирована, то есть все федерации достигли точки синхронизации.

Еще один набор услуг относится к сохранению и восстановлению выполнения федерации. Операция сохранения требует, чтобы как RTI, так и каждая федерация выполнили сохранение своего внутреннего состояния. Операция восстановления требует, чтобы как RTI, так и каждая федерация выполнили восстановление своего внутреннего состояния. Ключевые услуги:

Сохранять:

  • RequestFederationSave, который используется для инициации сохранения федерации.
  • InitiateFederateSave, который используется RTI для уведомления федератов о начале сохранения своего состояния.
  • FederateSaveComplete, который должен вызываться федерацией после завершения сохранения своего состояния.
  • FederationSaved, который используется RTI для уведомления федераций о сохранении федерации.

Восстановить:

  • RequestFederationRestore, который используется для инициирования восстановления федерации.
  • InitiateFederateRestore, который используется RTI для уведомления федераций о начале восстановления своего состояния
  • FederateRestoreComplete, который должен вызываться федерацией после завершения восстановления своего состояния.
  • FederationRestored, который используется RTI для уведомления федераций о восстановлении федерации.

Службы управления декларацией

Назначение служб управления декларациями, описанное в главе 5 спецификации интерфейса HLA,[5] состоит в том, чтобы позволить федерациям объявлять, какую информацию они хотят публиковать (отправлять) и подписываться (получать) на основе классов объектов и взаимодействий в FOM. RTI использует эту информацию для маршрутизации обновлений и взаимодействий с подписавшимися федерациями. Для класса объекта публикация и подписка выполняются для определенного набора атрибутов. Для классов взаимодействия все взаимодействие, включая все параметры, публикуется и подписывается. Ключевые услуги:

  • PublishObjectClassAttributes, который используется для публикации набора атрибутов для данного класса объектов.
  • SubscribeObjectClassAttributes, который используется для подписки на набор атрибутов для данного класса объектов.
  • PublishInteractionClass, который используется для публикации класса взаимодействия, включая все параметры.
  • SubscribeInteractionClass, который используется для подписки на класс взаимодействия, включая все параметры

Услуги по управлению объектами

Назначение сервисов управления объектами, описанное в главе 6 спецификации интерфейса HLA,[5] позволяет федерациям обмениваться информацией об экземплярах объектов и обмениваться взаимодействиями.

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

Объекты:

  • ReserveObjectInstanceName, который используется для резервирования имени, которое будет использоваться для экземпляра объекта.
  • RegisterObjectInstance, который используется для регистрации экземпляра объекта определенного класса объектов либо с зарезервированным именем, либо с автоматически созданным именем.
  • DiscoverObjectInstance, который используется RTI для уведомления федераций, подписывающихся на определенный класс объектов, о регистрации нового экземпляра объекта.
  • DeleteObjectInstance, который используется для удаления экземпляра объекта
  • RemoveObjectInstances, который используется RTI для уведомления федератов об удалении экземпляра объекта.

Атрибуты:

  • UpdateAttributeValues, который используется для предоставления обновленных значений атрибутов для экземпляра объекта.
  • ReflectAttributeValues, который используется RTI для уведомления федераций, подписывающихся на определенные атрибуты обновленных значений.

Взаимодействия:

  • SendInteraction, который используется для отправки взаимодействия определенного класса взаимодействия, включая значения параметров.
  • ReceiveInteraction, который используется RTI для доставки взаимодействия, включая значения параметров, федерациям, подписывающимся на определенный класс взаимодействия.

Услуги по управлению собственностью

Назначение служб управления собственностью, описанное в главе 7 спецификации интерфейса HLA,[5] заключается в динамическом управлении объединением, которое имитирует какой аспект экземпляра объекта. В HLA только одному федерату разрешено обновлять заданный атрибут данного экземпляра объекта. Эта федерация считается владельцем атрибута. Федерация, регистрирующая новый экземпляр объекта, автоматически становится владельцем всех публикуемых им атрибутов. В некоторых случаях атрибуты экземпляра объекта могут стать не принадлежащими, т.е. не принадлежащими какой-либо федерации.

Управление владением предоставляет услуги по передаче права собственности на один или несколько атрибутов во время выполнения, которые могут включать в себя федеративное удаление атрибута и другое федеративное получение атрибута. Существует два основных паттерна: «вытягивание», инициируемое федерацией-приобретателем, и «выталкивание», инициируемое федерацией-инвестором.

Ключевые услуги для инициирования «вытягивающего» владения:

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

Ключевые услуги для инициирования «принудительного» владения:

  • AttributeOwnershipDivestitureIfWanted, который используется федерацией, которая желает избавиться от атрибутов, только если есть какой-то другой федерат, готовый получить право владения этими атрибутами.
  • NegotiatedAttributeOwnershipDivestiture, который аналогичен, но может также заставить RTI попытаться найти нового владельца.
  • UnconditionalAttributeOwnershipDivestiture, который используется федерацией, желающей отказаться от владения, даже если не удается найти нового владельца.

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

Услуги тайм-менеджмента

Обмен информацией в федерации HLA происходит в режиме реального времени с немедленной доставкой сообщений (порядок приема, RO), если не было включено управление временем HLA. Цель HLA Time Management, описанная в главе 8 спецификации интерфейса HLA,[5] гарантирует причинно-следственную связь и правильный и последовательный обмен сообщениями с отметками времени (обновления и взаимодействия) в порядке отметок времени (TSO), независимо от того, выполняется ли федерация в реальном времени, быстрее, чем в реальном времени, или медленнее в реальном времени или как можно быстрее.

Некоторые важные концепции в HLA Time Management:

Логическое время: Ось времени в HLA, начиная с нуля. Логическое время используется для отметок времени и операций. Ось логического времени может быть отображена на время сценария объединения. Пример такого сопоставления: позволить нулю представлять время сценария 8:00 1 января 1066 года, а приращение на единицу - одну секунду сценария.

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

Предоставляется: RTI предоставляет федерацию (позволяет продвигаться) к определенному логическому времени, когда все сообщения с отметками времени до этого времени были доставлены. Затем федерация может безопасно начать вычисление сообщений с меткой времени в будущем. Эта временная метка не может быть раньше, чем предоставленное время плюс опережающий просмотр федерации.

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

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

Ограничено по времени: Федерация, которая принимает управляемые по времени события, считается ограниченной по времени, поскольку получение сообщений с меткой времени ограничивает свое временное опережение.

Основные принципы HLA Time Management заключаются в следующем:

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

Пример Lookahead, предоставленного и продвинутого:

  1. Федерация использует фиксированный временной шаг, равный 10, и имеет упреждающий просмотр 10.
  2. RTI предоставляет федерацию логическому времени 50. Таким образом, RTI гарантирует, что все сообщения с временным шагом, меньшим или равным 50, были доставлены федерации.
  3. Теперь у федерации есть все необходимые данные для правильного расчета и отправки сообщений в течение заданного времени плюс Lookahead, то есть 60.
  4. Когда федерация отправила все сообщения с отметкой времени 60, он запрашивает переход на время 60. Тем самым он обещает не отправлять никаких сообщений с отметкой времени меньше 70.
  5. RTI доставляет федерации все сообщения с отметкой времени меньше или равной 60. Затем он предоставляет федерату время 60.
  6. И Т. Д.

Если хотя бы одна федерация в федерации выполняет стимуляцию, то есть коррелирует свои запросы на опережение по времени с часами реального времени, федерация может работать в реальном времени или масштабированном реальном времени. Без стимуляции федерация будет работать как можно быстрее, что используется, например, в моделировании Монте-Карло.

Ключевые услуги включают:

  • EnableTimeConstrained и EnableTimeRegulating, которые включают эти режимы для федеративного
  • TimeAdvanceRequest, посредством которого федерация запрашивает продвижение до указанного логического времени
  • TimeAdvancedGrant, посредством которого RTI информирует федерацию о том, что ему предоставлено указанное логическое время.
  • EnableAsynchronousDelivery, который позволяет доставлять сообщения о порядке получения как когда федерация находится в разрешенном, так и в продвигающемся состоянии.

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

  • NextMessageRequest, посредством которого федерация запрашивает переход к метке времени следующего сообщения, подлежащего доставке в федерацию, или к указанному логическому времени, в зависимости от того, что имеет более низкую метку времени.

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

Ключевые услуги для GALT:

  • QueryGALT, который возвращает GALT для вызывающей федерации.

Более продвинутые услуги включают:

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

Службы управления распределением данных (DDM)

Цель DDM, описанная в главе 9 спецификации интерфейса HLA,[5] заключается в увеличении масштабируемости объединений путем выполнения дополнительной фильтрации подписанных данных за пределами подписок на классы и атрибуты.[11] Фильтрация может быть основана на непрерывных значениях (например, широте и долготе) или дискретных значениях (например, марки автомобиля).

Ключевые концепции DDM:

Измерение: именованный интервал (0..n), используемый для фильтрации, со значениями, начинающимися с 0 и заканчивающимися верхней границей n. Данные в области моделирования отображаются в одно или несколько измерений. Например, измерениями для географической фильтрации могут быть LatitudeDimension и LongitudeDimension. Параметр для фильтрации по марке автомобиля может быть CarBrandDimension.

Функция нормализации: функция, которая сопоставляет входные значения с целочисленными значениями, которые будут использоваться в измерении. Примером является то, что функция нормализации для LatitudeDimension может отображать значение широты в диапазоне от -90,0 до +90,0 с целым числом в диапазоне 0..179.Функция нормализации для CarBrandDimension может отображать набор марок автомобилей Kia, Ford, BMW и Peugeot с целым числом в диапазоне 0..3.

Классифицировать: интервал в измерении, определяемый нижней границей (включительно) и верхней границей (исключая).

Область, край: набор диапазонов, каждый из которых относится к определенному измерению. В приведенном выше примере регион может состоять из диапазона (3..5) для LatitudeDimension (55..65) для LongitudeDimension и (0..1) для CarBrandDimension. Во время выполнения создаются экземпляры реализаций регионов (объектов) для представления регионов. Диапазон региона может изменяться со временем.

Перекрытие регионов: две области перекрываются, если для всех общих параметров их диапазоны перекрываются.

Во время выполнения федерация может предоставлять регионы при подписке на атрибуты класса объектов и взаимодействия. Регионы также используются при отправке обновлений атрибутов и взаимодействий. При использовании DDM обновления атрибутов и взаимодействия будут доставляться только в случае перекрытия регионов.

Ключевые услуги для регионов:

  • CreateRegion, который используется для создания области с указанным набором измерений.
  • DeleteRegion, который используется для удаления региона.
  • CommitRegionModifications, который используется для изменения диапазонов измерения для региона.

Ключевые сервисы для обмена обновлениями атрибутов с DDM:

  • RegisterObjectInstanceWithRegions, который используется для регистрации экземпляра объекта с областями, связанными с его атрибутами.
  • AssociateRegionsForUpdates, который используется для связывания регионов с атрибутами экземпляра объекта.
  • SubscribeObjectClassAttributesWithRegions, который используется для подписки на атрибуты объектов, где регионы, используемые для подписки, перекрываются с регионами атрибутов.

Ключевые сервисы для обмена взаимодействиями с DDM:

  • SubscribeInteractionClassWithRegions, который используется для подписки на взаимодействия, где регионы, используемые для подписки, перекрываются с регионами взаимодействий.
  • SendInteractionsWithRegions, который используется для отправки взаимодействий со связанными регионами.

Службы поддержки

Службы поддержки HLA, описанные в главе 10 спецификации интерфейса HLA,[5] предоставлять ряд вспомогательных услуг. К ним относятся:

  • Получение дескрипторов (ссылок), которые будут использоваться в вышеуказанных сервисных вызовах.
  • Установка различных переключателей времени выполнения, в частности для советов (уведомлений).
  • Контроль доставки обратных вызовов.

Объектная модель управления

Назначение объектной модели управления, описанное в главе 11 спецификации интерфейса HLA,[5] заключается в предоставлении услуг по управлению федерацией. Это выполняется с помощью объекта MOM и классов взаимодействия. Объекты MOM определяются в специальном модуле FOM, называемом MIM, который автоматически загружается RTI. Ключевые особенности MOM:

  • Список и проверка свойств федератов.
  • Изучите свойства федерации.
  • Получить содержимое текущих модулей FOM и FOM.
  • Проверьте состояние управления временем.
  • Проверяйте и изменяйте публикации и подписки федераций.
  • Проверьте определенные показатели производительности.
  • Проверьте, какая федерация вызывает какие услуги HLA.
  • Проверьте состояние точек синхронизации.

Шаблон объектной модели (OMT)

OMT - это шаблон, используемый для описания объектных моделей федерации (FOM) и имитационных объектных моделей (SOM). FOM и SOM могут быть представлены в табличном формате или с использованием XML. Последний формат используется, когда FOM загружается в RTI.

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

В стандарте предусмотрен ряд предопределенных классов, типов данных, размеров и типов транспортировки. Они представлены в модуле FOM HLAstandardMIM.xml. Предопределенные концепции имеют префикс HLA, например HLAobjectRoot и HLAunicodeString.

Для OMT существует три различных XML-схемы:

  • Схема OMT DIF XML, которая проверяет, соответствует ли документ OMT базовому формату OMT, но не является ли он полным и имеет ссылочную целостность.
  • Схема OMT FDD XML, которая проверяет, что документ OMT содержит достаточно информации, чтобы его мог использовать RTI. Обратите внимание, что эта схема предоставляется в Спецификации интерфейса.
  • Схема соответствия OMT, которая проверяет, что документ OMT полон и имеет ссылочную целостность.

Таблица идентификации

Назначение идентификационной таблицы - предоставить метаданные о модели, чтобы облегчить повторное использование FOM / SOM или федераций.

Пример таблицы идентификации HLA

Указаны следующие поля:

  • Общие: имя, тип (FOM / SOM), версия, дата модификации, классификация безопасности, ограничение выпуска, цель, домен приложения, описание, ограничение использования и история использования
  • Ключевые слова: значения ключевых слов и используемая таксономия.
  • Контактное лицо (POC): Тип (Основной автор / Участник / Инициатор / Спонсор / Ответственный за выпуск / Технический POC), POC-имя, POC-организация, POC-телефон, POC-адрес электронной почты.
  • Ссылки: Тип (текстовый документ / электронная таблица / файл Powerpoint / автономный FOM / зависимый FOM / составленный из FOM), идентификация (имя документа или имя FOM)
  • Другой
  • Глиф (Значок)

Таблица структуры классов объектов

Назначение таблицы структуры классов объектов - указать иерархию классов (подкласс / суперкласс) классов объектов, которые используются для создания экземпляров объектов в федерации HLA. Атрибуты класса объекта наследуются от суперклассов к подклассам на основе этой иерархии. Корень дерева классов объектов известен как HLAobjectRoot. Пример полного имени класса объекта - HLAobjectRoot.Car.ElectricCar.

Пример таблицы классов объектов HLA

Следующие поля указаны для класса объекта в иерархии:

  • Имя
  • Публикация (Опубликовать / Подписка / ОпубликоватьПодписаться / Ни то, ни другое)

Таблица атрибутов

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

Пример таблицы атрибутов HLA

Следующие поля указаны для атрибута

  • Имя класса объекта, для которого он определен
  • Имя атрибута
  • Тип данных, определенный в таблице типов данных (см. Ниже)
  • Тип обновления (статический / периодический / условный / нет данных)
  • Состояние обновления
  • D / A (Divest / Acquire / NoTransfer / DivestAcquire): может ли атрибут быть изъят и / или приобретен с помощью HLA Ownership Services.
  • P / S (Publish / Subscribe / PublishSubscribe / Neither): может ли атрибут быть опубликован и / или подписан. В SOM эта информация относится к описанной Федерации, в FOM - ко всей федерации.
  • Доступные размеры
  • Транспортировка (Надежные / BestEffort / другие перевозки, указанные в таблице Транспортировка)
  • Заказ (получение / отметка времени): порядок доставки обновлений атрибутов.

Таблица структуры классов взаимодействия

Назначение таблицы структуры классов взаимодействия - указать иерархию классов (подкласс / суперкласс) классов взаимодействия, которые используются для обмена взаимодействиями в федерации HLA. Параметры класса взаимодействия наследуются от суперклассов к подклассам на основе этой иерархии. Корень дерева классов взаимодействия известен как HLAinteractionRoot. Примером полного имени класса взаимодействия является HLAinteractionRoot.CarCommand.Start.

Пример таблицы классов взаимодействия HLA

Следующие поля указаны для класса взаимодействия в иерархии:

  • Имя
  • Публикация (Опубликовать / Подписка / ОпубликоватьПодписаться / Ни то, ни другое)

Таблица параметров

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

Пример таблицы параметров HLA

Таблица размеров

Цель таблицы измерений - указать измерения DDM, используемые для атрибутов и классов взаимодействия.

Таблица представления времени

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

Таблица тегов, предоставляемая пользователем

Пользовательский тег может быть предоставлен при вызове определенных служб HLA. Назначение таблицы тегов, предоставляемой пользователем, - указать типы данных этих тегов.

Таблица синхронизации

Назначение таблицы синхронизации - указать точки синхронизации, используемые в федерации.

Таблица видов транспорта

Назначение таблицы видов транспортировки - указать доступные виды транспортировки. Существует два предопределенных типа транспортировки: HLAreliable и HLAbestEffort.

Таблица скорости обновления

Цель таблицы частоты обновления - указать доступные максимальные частоты обновления.

Таблица переключателей

Поведение RTI во время выполнения можно контролировать с помощью ряда предопределенных переключателей. Цель таблицы переключателей - предоставить начальные значения для этих переключателей. Некоторые переключатели также можно обновлять во время выполнения.

Типы данных

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

Таблица представления основных данных

Цель базовой таблицы представления данных - предоставить двоичные представления для использования в других таблицах. В стандарте HLA предоставляется ряд предопределенных базовых типов данных: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAintegerLA, HLAinteger16LE, HLAintegerLA и HLAinteger64 Набор базовых типов данных обычно не расширяется пользовательскими базовыми типами данных.

Таблица простых типов данных

Пример простой таблицы типов данных HLA

Цель простой таблицы типов данных - описать простые скалярные элементы данных. В стандарте HLA предоставляется ряд предопределенных простых типов данных: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time и HLAfloat64time. Обычно в FOM включают простые типы данных, определяемые пользователем.

Таблица перечисленных типов данных

Пример таблицы перечислимых типов данных HLA

Цель таблицы перечисленных типов данных - описать элементы данных, которые могут принимать конечный дискретный набор значений. В стандарте предусмотрен один предопределенный перечислимый тип данных: HLAboolean. Обычно в FOM включаются перечисляемые типы данных, определенные пользователем.

Таблица типов данных массива

Пример таблицы типов данных массива HLA

Назначение таблицы перечислимых типов данных - описать массивы элементов данных (простые, перечисляемые, массивы, фиксированные записи или вариантные записи). В стандарте HLA предоставляется ряд предопределенных простых типов данных: HLAASCIIstring, HLAunicodeString, HLAopaqueData и HLAtoken. Обычно в FOM включаются типы данных массива, определенные пользователем.

Таблица типов данных фиксированной записи

Пример таблицы типов данных фиксированной записи HLA

Назначение таблицы типов данных с фиксированной записью - описать записи с фиксированным набором элементов данных (простые, перечисляемые, массивы, фиксированные записи или вариантные записи). Обычно в FOM включают простые типы данных, определяемые пользователем. Стандарт HLA не предоставляет никаких предопределенных простых типов данных.

Таблица типов данных записи варианта

Таблица заметок

Целью примечаний к таблице является предоставление аннотаций и дополнительных описаний элементов в других таблицах.

Правила HLA

Правила HLA описывают обязанности федераций и присоединяющихся федераций.[12]

  1. Федерации должны иметь объектную модель федерации HLA (FOM), задокументированную в соответствии с шаблоном объектной модели HLA (OMT).
  2. В федерации все представления объектов в FOM должны быть в федерациях, а не в инфраструктуре времени выполнения (RTI).
  3. Во время выполнения федерации весь обмен данными FOM между федерациями должен происходить через RTI.
  4. Во время выполнения федерации федерации должны взаимодействовать с инфраструктурой времени выполнения (RTI) в соответствии со спецификацией интерфейса HLA.
  5. Во время выполнения федерации атрибут экземпляра объекта должен принадлежать только одному федерату в любой момент времени.
  6. Объединения должны иметь имитационную объектную модель HLA (SOM), задокументированную в соответствии с шаблоном объектной модели HLA (OMT).
  7. Федерации должны иметь возможность обновлять и / или отражать любые атрибуты объектов в их SOM и отправлять и / или получать взаимодействия объектов SOM извне, как указано в их SOM.
  8. Федерации должны иметь возможность передавать и / или принимать право владения атрибутом динамически во время выполнения федерации, как указано в их SOM.
  9. Федерации должны иметь возможность изменять условия, при которых они предоставляют обновления атрибутов объектов, как указано в их SOM.
  10. Федерации должны иметь возможность управлять местным временем таким образом, чтобы это позволяло им координировать обмен данными с другими членами федерации.

HLA Evolved

Стандарт IEEE 1516 был пересмотрен группой разработки продуктов SISO HLA-Evolved и утвержден 25 марта 2010 г. Советом по стандартизации IEEE. Пересмотренный стандарт IEEE 1516–2010 включает текущие интерпретации стандартов Министерства обороны США и EDLC API, расширенную версию SISO DLC API. Другие важные улучшения включают:

  • Расширенная поддержка XML для FOM / SOM, такая как схемы и расширяемость
  • Услуги поддержки отказоустойчивости
  • Поддержка веб-служб (WSDL) / API
  • Модульные ФОМы
  • Снижение частоты обновления
  • Помощники кодирования
  • Расширенная поддержка дополнительной транспортировки (например, QoS, IPv6, ...)
  • Стандартизированные представления времени

Соответствие Федерации

Чтобы гарантировать надлежащее взаимодействие между симуляциями, определен способ тестирования федеративного соответствия. Это включает в себя обеспечение того, чтобы каждый класс и взаимодействие, перечисленные в SOM для конкретной федерации, использовались в соответствии с описанным использованием: «PublishSubscribe», «Publish», «Subscribe» или «None».

STANAG 4603

HLA (как в текущей версии IEEE 1516, так и в ее предшественнице версии 1.3) является предметом НАТО соглашение о стандартизации (STANAG 4603) для моделирования и моделирования: Стандарты архитектуры моделирования и имитации для технического взаимодействия: архитектура высокого уровня (HLA).[13]

Связанные стандарты

Базовая объектная модель

В Базовая объектная модель (BOM), SISO-STD-003-2006 является родственным стандартом SISO для обеспечения лучшего повторного использования и возможности компоновки для моделирования HLA. Он позволяет указать концептуальные модели и сопоставить их с HLA FOM.[14]

Альтернативы

Что касается индустрии распределенного моделирования и моделирования (DM&S), наиболее часто используемой альтернативой HLA для моделирования военных платформ в реальном времени является Распределенное интерактивное моделирование (DIS), IEEE 1278.1-2012, протокол моделирования. Наиболее Поставщики HLA RTI также используют DIS в своих продуктах. Что касается приложений промежуточного слоя, которые наиболее точно соответствуют функциям HLA, например, функция публикации и подписки (P&S), см. Служба распространения данных (DDS) который имеет многие из тех же характеристик, но имеет открытый протокол передачи данных для взаимодействия системы.[15]

Критика

HLA - это По промежуточного слоя, ориентированного на сообщения который определяется как набор услуг, предоставляемых C ++ или же Ява API. Стандартизованного сетевого протокола не существует. Участники федерации должны использовать библиотеки RTI от одного и того же поставщика и, как правило, одной и той же версии, что в некоторых случаях воспринимается как недостаток.[16]

Смотрите также

Рекомендации

  1. ^ а б Куль, Фредерик; Уэтерли, Ричард; Дахманн, Джудит (18 октября 1999 г.). Создание систем компьютерного моделирования: введение в архитектуру высокого уровня (1-е изд.). Прентис Холл. ISBN  0130225118.
  2. ^ а б Дахманн, Джудит (1997). "Архитектура высокого уровня Министерства обороны" (PDF). Труды Зимней конференции по моделированию 1997 г.: 142–149. Дои:10.1145/268437.268465. ISBN  078034278X.
  3. ^ STANAG 4603: Стандарты архитектуры моделирования и имитации для технического взаимодействия: архитектура высокого уровня (HLA). НАТО.
  4. ^ а б Стандарт IEEE для моделирования и моделирования (M&S) Архитектура высокого уровня (HLA) - Структура и правила. Компьютерное общество IEEE. 18 августа 2010 г. ISBN  978-0-7381-6251-5.
  5. ^ а б c d е ж грамм час я j Стандарт IEEE для моделирования и симуляции (M&S) Архитектура высокого уровня (HLA) - Спецификация федеративного интерфейса. Компьютерное общество IEEE. 18 августа 2010 г. ISBN  978-0-7381-6247-8.
  6. ^ а б Стандарт IEEE для моделирования и моделирования (M&S) Архитектура высокого уровня (HLA) - Спецификация шаблона объектной модели (OMT). Компьютерное общество IEEE. 18 августа 2010 г. ISBN  978-0-7381-6249-2.
  7. ^ Мёллер, Бьёрн; Морс, Кэтрин Л; Лайтнер, Майк; Литтл, Рид; Лутц, Боб (апрель 2008 г.). «HLA Evolved - сводка основных технических улучшений». Материалы семинара Spring Simulation Interoperability Workshop.
  8. ^ Мёллер, Бьёрн; Лёфстранд, Бьёрн (сентябрь 2009 г.). «Начало работы с модулями FOM». Труды семинара по совместимости моделирования падения 2009 г..
  9. ^ Мёллер, Бьёрн; Лёф, Стаффан (сентябрь 2006 г.). «Обзор управления HLA Evolved Web Service API». Труды семинара по совместимости моделирования падения 2006 г..
  10. ^ Мёллер, Бьёрн; Карлссон, Микаэль; Лёфстранд, Бьёрн (апрель 2005 г.). «Разработка отказоустойчивых федераций с использованием HLA Evolved». Труды семинара по совместимости моделирования Spring Simulation 2005.
  11. ^ Мёллер, Бьёрн; Фредрик, Антелиус; Мартин, Йоханссон; Микаэль, Карлссон (сентябрь 2016 г.). «Построение масштабируемого распределенного моделирования: шаблоны проектирования для HLA DDM». Труды семинара по совместимости Fall Simulation 2016. Получено 13 ноября 2019.
  12. ^ НАС. Офис оборонного моделирования и моделирования (2001). RTI 1.3 - Руководство программиста нового поколения, версия 4. Министерство обороны США.
  13. ^ «Разработка архитектуры высокого уровня STANAG (MSG-033)». Получено 3 марта, 2015.
  14. ^ Стандарт спецификации SISO
  15. ^ Доши, Раджив; Кастеллот, Херардо-Пардо (2006). «Сравнение HLA и DDS» (PDF). Инновации в реальном времени. Получено 3 марта, 2015. Цитировать журнал требует | журнал = (помощь)
  16. ^ Granowetter, Len. «Проблемы взаимодействия RTI - стандарты API, стандарты проводов и мосты RTI». Получено 14 марта 2018.

внешняя ссылка