Архитектура высокого уровня ( HLA ) — это стандарт распределенного моделирования, используемый при построении моделирования для более крупных целей путем объединения (объединения) нескольких симуляций. [1] Стандарт был разработан в 1990-х годах под руководством Министерства обороны США [2] и позже был преобразован в открытый международный стандарт IEEE. Это рекомендуемый стандарт НАТО в соответствии со стандартом STANAG 4603. [3] Сегодня HLA используется в ряде областей, включая оборону и безопасность, а также гражданские приложения.
Цель HLA — обеспечить совместимость и повторное использование. Ключевые свойства HLA:
HLA формирует основу для разработки стандартизированных и расширяемых FOM в различных сообществах, например, в аэрокосмической и оборонной отраслях.
Архитектура определяет следующие компоненты.
Вместе вышеперечисленные компоненты образуют Федерацию .
Стандарт HLA состоит из трех частей:
HLA был инициирован в начале 1990-х годов, когда доктор Анита К. Джонс , директор по оборонным исследованиям и разработкам Министерства обороны США, дала Управлению оборонного моделирования и моделирования (DMSO) задачу «обеспечить функциональную совместимость и возможность повторного использования оборонных моделей». и моделирование». [1] В 1995 году DMSO сформулировала концепцию моделирования и симуляции и разработала генеральный план моделирования и симуляции, который включал архитектуру высокого уровня.
Уже существовало два протокола для взаимодействия M&S: распределенное интерактивное моделирование (DIS), ориентированное на моделирование на уровне платформы в реальном времени с фиксированной объектной моделью, и протокол моделирования на уровне агрегатов (ALSP), ориентированное на моделирование агрегатов с управлением временем, управлением собственностью и гибкими объектные модели, называемые моделями конфедерации. Целью HLA было предоставить один унифицированный стандарт, который отвечал бы требованиям совместимости моделирования всех компонентов Министерства обороны США. [2]
Разработка HLA основывалась на четырех прототипических федерациях: Федерации прототипов платформ, Протофедерации совместного обучения, Протофедерации анализа и Федерации инженерных прототипов. Спецификация HLA была прототипирована и усовершенствована, пока наконец не была выпущена HLA 1.3. Чтобы облегчить использование за пределами оборонного сообщества, HLA был затем преобразован в стандарт IEEE, поддерживаемый Организацией стандартов совместимости моделирования (SISO). Чтобы облегчить миграцию для пользователей DIS, объектная модель федерации, соответствующая фиксированной объектной модели DIS, также была разработана как эталонная модель платформы реального времени ( RPR FOM ).
Существуют следующие версии HLA:
HLA 1.3 был опубликован ДМСО в марте 1998 года. Это состоит из:
Министерство обороны США также опубликовало интерпретации HLA 1.3:
HLA IEEE 1516-2000 был опубликован IEEE в 2000 году. Это состоит из:
Основные улучшения в IEEE 1516-2000 включали FOM на основе XML с подробными спецификациями типов данных, а также улучшенный дизайн DDM.
Стандарт IEEE 1516-2000 также был дополнен рекомендуемым процессом разработки, а также рекомендуемым процессом VV&A:
Вскоре выяснилось, что стандарт 1516-2000 имеет API, которые немного различаются для каждой реализации RTI. SISO разработала стандарт с альтернативными API-интерфейсами C++ и Java, совместимыми с динамическими ссылками (DLC):
API-интерфейсы DLC позже были объединены в основной стандарт.
Стандарт IEEE 1516-2010 был опубликован IEEE в августе 2010 года и широко известен как HLA Evolved. [7] В его состав входят:
Основные улучшения в IEEE 1516-2010 включают модульные FOM, [8] включение API-интерфейсов DLC в C++ и Java, API веб-служб [9] и отказоустойчивость. [10]
Машиночитаемые части этой версии HLA, такие как схемы XML, API C++, Java и WSDL , а также образцы FOM/SOM, можно загрузить из области загрузки IEEE 1516 на веб-сайте IEEE. Полные тексты стандартов доступны членам SISO бесплатно или их можно приобрести в магазине IEEE.
Разработка новой версии HLA началась SISO в январе 2016 года и продолжается в настоящее время.
Стандарт 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, и каждое объединение выполнили сохранение своего внутреннего состояния. Операция восстановления требует, чтобы и RTI, и каждое объединение выполнили восстановление своего внутреннего состояния. Ключевые услуги:
Сохранять:
Восстановить:
Цель служб управления объявлениями, описанная в главе 5 спецификации интерфейса HLA [5] , состоит в том, чтобы позволить федератам объявлять, какую информацию они хотят публиковать (отправлять) и подписываться (получать) на основе классов объектов и взаимодействия в FOM. . RTI использует эту информацию для маршрутизации обновлений и взаимодействия с подписавшимися федерациями. Для класса объектов публикация и подписка выполняются для определенного набора атрибутов. Для классов взаимодействия публикуется и подписывается все взаимодействие, включая все параметры. Ключевые услуги:
Целью служб управления объектами, описанной в главе 6 спецификации интерфейса HLA [5] , является предоставление возможности федерациям обмениваться информацией об экземплярах объектов и обмениваться взаимодействиями.
Имена экземпляров объектов могут быть зарезервированы или сгенерированы автоматически. Федераты могут регистрировать экземпляры объектов указанных классов объектов, которые затем обнаруживаются подписавшимися федерациями. Атрибуты этих экземпляров объектов можно обновлять. Эти обновления будут доступны подписавшимся федератам. Взаимодействия можно отправлять. Эти взаимодействия будут доставлены подписавшимся федератам. Ключевые услуги:
Объекты:
Атрибуты:
Взаимодействия:
Целью сервисов управления владением, описанных в главе 7 спецификации интерфейса HLA [5] , является динамическое управление тем, какая федерация имитирует какой аспект экземпляра объекта. В HLA только одному федератору разрешено обновлять данный атрибут данного экземпляра объекта. Этот федерат считается владельцем атрибута. Федерация, регистрирующая новый экземпляр объекта, автоматически становится владельцем всех публикуемых им атрибутов. В некоторых случаях атрибуты экземпляра объекта могут стать бесхозными, т.е. не принадлежать какому-либо объединению.
Управление владением предоставляет услуги по передаче права собственности на один или несколько атрибутов во время выполнения, которые могут включать в себя передачу атрибута федерацией и приобретение атрибута другой федерацией. Существует две основные модели: «вытягивание», инициируемое приобретающей федерацией, и «толкание», инициируемое продающей федерацией.
Ключевые услуги для инициирования «вытягивающего» владения:
Ключевые услуги для инициирования «проталкивающего» владения:
Все экземпляры объектов имеют предопределенный атрибут HLAPrivilegeToDeleteObject. Только владелец этого атрибута экземпляра объекта может удалить экземпляр объекта. Право собственности на этот атрибут можно передать во время выполнения с помощью описанных выше операций.
Обмен информацией в федерации HLA происходит в режиме реального времени с немедленной доставкой сообщений (заказ на получение, RO), если только не включено управление временем HLA. Цель управления временем HLA, описанная в главе 8 спецификации интерфейса HLA [5] , состоит в том, чтобы гарантировать причинно-следственную связь, а также правильный и последовательный обмен сообщениями с отметками времени (обновления и взаимодействия) в порядке отметок времени (TSO), независимо от того, федерация выполняется в режиме реального времени, быстрее, чем в реальном времени, медленнее, чем в реальном времени или настолько быстро, насколько это возможно.
Некоторые важные концепции управления временем HLA:
Логическое время : ось времени в HLA, начиная с нуля. Логическое время используется для временных меток и операций управления временем. Логическую ось времени можно сопоставить со сценарным временем федерации. Примером такого сопоставления является то, что ноль представляет время сценария 8:00 1 января 1066 года, а приращение на единицу представляет одну секунду сценария.
Lookahead : временной интервал, определяющий наименьшее время в будущем, в течение которого федерация будет создавать сообщения. Для федерации с фиксированным шагом по времени это обычно длина шага по времени.
Предоставлено : RTI предоставляет федерации (разрешает продвижение) определенное логическое время, когда все сообщения с отметкой времени до этого времени были доставлены. Затем федерация может безопасно начать рассчитывать сообщения с отметкой времени в будущем. Эта временная метка не может быть раньше, чем предоставленное время плюс прогнозируемое время федерации.
Продвижение : когда федерация завершила создание данных за отведенное время плюс просмотр вперед, она может запросить перенос на более позднее время, что также означает, что она обещает больше не создавать сообщения с отметкой времени меньшей, чем запрошенное время плюс просмотр вперед. Федерация сейчас находится в наступающем состоянии.
Регулирование времени : федерация, которая отправляет события с отметкой времени, считается регулирующей время, поскольку этим может регулироваться продвижение времени другими федерациями.
Ограничено по времени : Федерация, получающая события, управляемые по времени, считается ограниченной по времени, поскольку прием сообщений с отметкой времени ограничивает его продвижение по времени.
Основные принципы HLA Time Management заключаются в следующем:
Пример просмотра вперед, предоставленного и продвигающегося:
Если хотя бы один федерат в федерации выполняет синхронизацию, т. е. коррелирует свои запросы на опережение по времени с часами реального времени, федерация может работать в реальном времени или в масштабированном реальном времени. Без изменения темпа федерация будет работать настолько быстро, насколько это возможно (например, федерации, которым не требуется взаимодействие человека во время выполнения или интерфейсы с системами, зависящими от часов реального времени, могут работать так быстро, как позволяют вычислительные ресурсы).
Ключевые услуги включают в себя:
Для моделирования, управляемого событиями, федерат также может запросить переход к следующему событию, используя следующую услугу:
Еще одним важным понятием является наибольшее доступное логическое время (GALT). Максимальное время, которое может быть предоставлено каждой федерации, зависит от времени, которое было предоставлено другим федерациям, а также от их прогноза. GALT для федерации определяет, в какой степени федерация может быть предоставлена без необходимости ждать предоставления других федераций. Это особенно интересно для федерации, которая поздно присоединяется к федерации, управляемой по времени.
Ключевые услуги GALT:
Более продвинутые услуги включают в себя:
Целью 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 обновления атрибутов и взаимодействия будут доставляться только в том случае, если регион перекрывается.
Ключевые сервисы для регионов:
Ключевые сервисы для обмена обновлениями атрибутов с DDM:
Ключевые сервисы для обмена взаимодействиями с DDM:
Службы поддержки HLA, описанные в главе 10 спецификации интерфейса HLA, [5] предоставляют ряд вспомогательных услуг. К ним относятся:
Целью объектной модели управления, описанной в главе 11 спецификации интерфейса HLA [5] , является предоставление услуг по управлению федерацией. Это выполняется с помощью объекта MOM и классов взаимодействия. Объекты MOM определяются в специальном модуле FOM, называемом MIM, который автоматически загружается RTI. Ключевые особенности MOM включают в себя:
OMT — это шаблон, используемый для описания объектных моделей федерации (FOM) и объектных моделей моделирования (SOM). FOM и SOM могут быть представлены в табличном формате или с использованием XML. Последний формат используется, когда FOM загружается в RTI.
В более ранних версиях HLA FOM были монолитными, но текущая версия стандарта поддерживает модульные FOM, т.е. в RTI может быть предоставлено несколько модулей, охватывающих различные аспекты обмена информацией.
В стандарте предусмотрен ряд предопределенных классов, типов данных, измерений и типов транспортировки. Они предоставляются в модуле FOM HLAstandardMIM.xml. Предопределенные концепции имеют префикс HLA, например HLAobjectRoot и HLAunicodeString.
Для OMT существует три разные XML-схемы:
Цель идентификационной таблицы — предоставить метаданные о модели, чтобы облегчить повторное использование FOM/SOM или федераций.
Указываются следующие поля:
Цель таблицы структуры классов объектов — указать иерархию классов (подкласс/суперкласс) классов объектов, которые используются для создания экземпляров объектов в федерации HLA. Атрибуты класса объекта наследуются от суперклассов к подклассам на основе этой иерархии. Корень дерева классов объектов известен как HLAobjectRoot. Пример полного имени класса объекта: HLAobjectRoot.Car.ElectricCar.
Для класса объектов в иерархии указываются следующие поля:
Цель таблицы атрибутов — указать атрибуты, доступные для данного класса объектов. Поскольку атрибуты наследуются, класс объектов будет объединять все атрибуты, которые определены локально в классе объектов или указаны в любом прямом или косвенном суперклассе.
Для атрибута указаны следующие поля
Цель таблицы структуры классов взаимодействия — указать иерархию классов (подкласс/суперкласс) классов взаимодействия, которые используются для обмена взаимодействиями в федерации HLA. Параметры класса взаимодействия наследуются от суперклассов к подклассам на основе этой иерархии. Корень дерева классов взаимодействия известен как HLAinteractionRoot. Примером полного имени класса взаимодействия является HLAinteractionRoot.CarCommand.Start.
Для класса взаимодействия в иерархии указаны следующие поля:
Цель таблицы параметров — указать параметры, доступные для данного класса взаимодействия. Поскольку параметры наследуются, класс взаимодействия будет иметь объединение всех параметров, которые определены локально в классе взаимодействия или указаны в любом прямом или косвенном суперклассе.
Целью таблицы измерений является указание измерений DDM, используемых для атрибутов и классов взаимодействия.
Целью таблицы представления времени является указание типов данных, используемых службами управления временем.
Пользовательский тег может быть предоставлен при вызове определенных служб HLA. Целью таблицы тегов, предоставляемой пользователем, является указание типов данных этих тегов.
Цель таблицы синхронизации — указать точки синхронизации, используемые в федерации.
Целью таблицы видов транспортировки является указание доступных видов транспортировки. Существует два предопределенных типа транспортировки: HLAreliable и HLAbestEffort.
Цель таблицы частоты обновления — указать доступные максимальные скорости обновления.
Поведением RTI во время выполнения можно управлять с помощью ряда предопределенных переключателей. Цель таблицы переключателей — предоставить начальные значения для этих переключателей. Некоторые переключатели также можно обновлять во время выполнения.
Целью таблиц типов данных является предоставление спецификаций типов данных, используемых для атрибутов, параметров, измерений, представления времени, предоставленных пользователем тегов и точек синхронизации. Существует шесть категорий типов данных с отдельным табличным форматом для каждой из них.
Целью базовой таблицы представления данных является предоставление двоичных представлений для использования в других таблицах. В стандарте HLA предусмотрен ряд предопределенных базовых типов данных: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteger64LE, HLAfloat32LE, HLAfloat64LE, HLAoctetPairLE. и HLAоктет. Набор базовых типов данных обычно не расширяется за счет определяемых пользователем базовых типов данных.
Целью таблицы простых типов данных является описание простых скалярных элементов данных. В стандарте HLA предусмотрен ряд предопределенных простых типов данных: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time и HLAfloat64time. Обычно в FOM включаются определяемые пользователем простые типы данных.
Целью таблицы перечислимых типов данных является описание элементов данных, которые могут принимать конечный дискретный набор значений. В стандарте предусмотрен один предопределенный перечислимый тип данных: HLAboolean. Обычно в FOM включают определяемые пользователем перечисляемые типы данных.
Цель таблицы перечислимых типов данных — описать массивы элементов данных (простые, перечисляемые, массивы, фиксированные записи или варианты записей). В стандарте HLA предусмотрен ряд предопределенных простых типов данных: HLAASCIIstring, HLAunicodeString, HLAopaqueData и HLAtoken. Обычно в FOM включаются определяемые пользователем типы данных массива.
Целью таблицы типов данных фиксированных записей является описание записей с фиксированным набором элементов данных (простые, перечислимые, массивы, фиксированные записи или варианты записей).
Целью таблицы типов данных вариантов записей является описание записей, которые могут содержать разные предопределенные наборы элементов данных. Различные наборы называются Альтернативами. Какая альтернатива применима к данной вариантной записи, указывается элементом данных, называемым дискриминантом.
Цель таблицы примечаний — предоставить аннотации и дополнительные описания элементов в других таблицах.
Правила HLA описывают обязанности федераций и присоединяющихся федераций. [12]
Стандарт IEEE 1516 был пересмотрен Группой разработки продуктов SISO HLA-Evolved и одобрен 25 марта 2010 года Советом по стандартизации IEEE. Пересмотренный стандарт IEEE 1516–2010 включает текущие интерпретации стандартов Министерства обороны США и API EDLC, расширенную версию API SISO DLC. Другие важные улучшения включают в себя:
Чтобы обеспечить правильное взаимодействие между симуляциями, определен способ тестирования федерального соответствия. Это включает в себя обеспечение того, чтобы каждый класс и взаимодействие, перечисленные в 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), см. Службу распространения данных (DDS) , которая имеет многие из тех же характеристик, но имеет открытый протокол беспроводной связи для взаимодействия систем. [15]
HLA — это промежуточное программное обеспечение, ориентированное на сообщения , которое определяется как набор служб, предоставляемых C++ или Java API . Стандартизированного протокола передачи данных не существует. Участники федерации должны использовать библиотеки RTI от одного и того же поставщика и обычно одной и той же версии, что в некоторых случаях воспринимается как недостаток. [16] Большинство современных инструментов также обеспечивают взаимосвязь через сокеты.
{{cite journal}}: Требуется цитировать журнал |journal=( помощь )