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

Эта статья о стандарте IEEE для распределенного моделирования. Чтобы узнать о других значениях, см. « Высокий и низкий уровень» .

Архитектура высокого уровня ( HLA ) — это стандарт распределенного моделирования, используемый при построении моделирования для более крупных целей путем объединения (объединения) нескольких симуляций. Стандарт был разработан в 1990-х годах под руководством Министерства обороны США. и позже был преобразован в открытый международный стандарт IEEE. Это рекомендуемый стандарт НАТО в рамках STANAG 4603. Сегодня HLA используется во многих областях, включая оборону и безопасность, а также гражданские приложения.

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

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

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

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

Компоненты федерации HLA

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

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

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

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

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

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

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

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

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

HLA 1.3

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

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

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

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

ХЛА 1516-2000

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

• IEEE Std 1516–2000 - Стандарт моделирования и моделирования. Архитектура высокого уровня. Структура и правила.
• IEEE Std 1516.1–2000 – Стандарт моделирования и моделирования архитектуры высокого уровня – Спецификация федерального интерфейса
• Ошибки IEEE 1516.1–2000 (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 Распределенное моделирование и процесс выполнения ( 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 был опубликован IEEE в августе 2010 года и широко известен как HLA Evolved. Он состоит из:

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

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

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

ХЛА 1516-20ХХ (ХЛА 4)

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

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

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

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

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

• Инфраструктура времени выполнения (RTI) : Программное обеспечение, предоставляющее стандартизированный набор сервисов, как указано в спецификации HLA Federate Interface. Существует семь групп обслуживания.
• Федерация : система, такая как симуляция, инструмент или интерфейс для живых систем, которая подключается к 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), которые представляют собой библиотеки, используемые федерациями. Услуги предоставляются через API C++ или Java , а также с использованием веб-сервисов. В API C++ и Java службы вызываются с помощью вызовов экземпляра класса RTI Ambassador. RTI доставляет информацию федерации с помощью обратных вызовов, которые доставляются с помощью вызовов экземпляра класса Federate Ambassador. В API веб-служб, определенном с помощью WSDL , вызовы и обратные вызовы извлекаются федерацией с использованием запросов и ответов веб-служб.

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

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

Цель служб управления федерацией, описанная в главе 4 спецификации интерфейса HLA, предназначен для управления выполнением федерации, а также операциями в масштабе всей федерации, такими как точки синхронизации и сохранение/восстановление.

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

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

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

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

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

Сохранять:

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

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

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

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

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

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

Службы управления объектами

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

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

Объекты:

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

Атрибуты:

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые важные концепции управления временем HLA:

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

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

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

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

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

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

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

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

Пример просмотра вперед, предоставленного и продвигающегося:

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые концепции 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, предоставить ряд вспомогательных услуг. К ним относятся:

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

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

Цель объектной модели управления, описанная в главе 11 спецификации интерфейса HLA, заключается в предоставлении услуг по управлению федерацией. Это выполняется с помощью объекта 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-схемы:

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

Идентификационная таблица

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

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

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

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

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

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

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

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

• Имя
• Публикация (публикация/подписка/публикацияподписка/ни то)

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

Цель таблицы атрибутов — указать атрибуты, доступные для данного класса объектов. Поскольку атрибуты наследуются, класс объектов будет объединять все атрибуты, которые определены локально в классе объектов или указаны в любом прямом или косвенном суперклассе.

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

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

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

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

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

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

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

• Имя
• Публикация (публикация/подписка/публикацияподписка/ни то)

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновить таблицу тарифов

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

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

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

Типы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица примечаний

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

HLA-правила

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

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 развитый

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

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

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

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

Станаг 4603

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

Сопутствующие стандарты

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

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

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

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

Критика

HLA — это промежуточное программное обеспечение, ориентированное на сообщения , которое определяется как набор служб, предоставляемых C++ или Java API . Стандартизированного протокола передачи данных не существует. Участники федерации должны использовать библиотеки RTI от одного и того же поставщика и обычно одной и той же версии, что в некоторых случаях воспринимается как недостаток. Большинство современных инструментов также обеспечивают взаимодействие через сокеты.

См. также

• Перечень коммерческих и некоммерческих ИРТ
• Компьютерное моделирование
• Распределенные вычисления
• Организация по стандартизации совместимости моделирования

Внешние ссылки

• Учебное пособие по HLA : бесплатное учебное пособие (PDF)

Внешние ссылки

• Ошибки стандарта IEEE для моделирования и симуляции (M&S) Архитектура высокого уровня (HLA) — спецификация федерального интерфейса
• Интерпретации Министерства обороны (DoD) серии стандартов IEEE 1516–2000, выпуск 2 (1 июля 2003 г.)