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

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

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

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

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

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

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

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

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

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

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

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

Разработка HLA основывалась на четырех прототипических федерациях: Platform Prototype Federation, Joint Training Protofederation, Analysis Protofederation и Engineering Prototype Federation. Спецификация HLA была прототипирована и доработана, пока HLA 1.3 не был окончательно выпущен. Чтобы облегчить использование за пределами оборонного сообщества, HLA затем был переведен в стандарт IEEE, поддерживаемый Simulation Interoperability Standards Organization (SISO). Чтобы облегчить миграцию для пользователей DIS, также была разработана модель объектов федерации, соответствующая фиксированной объектной модели DIS, как Real-time Platform Reference FOM ( RPR FOM ).

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

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

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

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

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

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

• 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 разработал стандарт с альтернативными, совместимыми с динамическими ссылками (DLC) C++ и Java API:

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

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

Стандарт 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 и API WSDL , а также образцы FOM/SOM можно загрузить из раздела загрузок IEEE 1516 на веб-сайте IEEE. Полные тексты стандартов доступны бесплатно для членов SISO или могут быть приобретены в магазине IEEE.

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

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

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

• Run-time Infrastructure (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 ^[5] , является управление выполнением федерации, а также операциями в масштабах всей федерации, такими как точки синхронизации и сохранение/восстановление.

Один набор служб управления федерацией управляет подключением к 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 ^[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 только одному федерату разрешено обновлять заданный атрибут заданного экземпляра объекта. Этот федерат считается владельцем атрибута. Федерат, регистрирующий новый экземпляр объекта, автоматически становится владельцем всех публикуемых им атрибутов. В некоторых случаях атрибуты экземпляра объекта могут стать бесхозными, т. е. не принадлежащими ни одному федерату.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во время выполнения федерат может предоставлять регионы при подписке на атрибуты и взаимодействия класса объекта. Регионы также используются при отправке обновлений атрибутов и взаимодействий. При использовании 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 — это шаблон, используемый для описания моделей объектов федерации (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 или федераций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правила 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. Федерации должны иметь возможность управлять местным временем таким образом, чтобы это позволяло им координировать обмен данными с другими членами федерации.

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

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

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

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), см. Data Distribution Service (DDS) , которая имеет много тех же характеристик, но имеет открытый протокол on-the-wire для системного взаимодействия. ^[15]

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

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

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

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