Архитектура высокого уровня (HLA) против распределенного интерактивного моделирования (DOS)

Question

Есть ли обзор высокого уровня HLA против Дес Структура моделирования? Может ли один хост другого и наоборот?

Answer 1

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

Дес

• Стандарт определяет расположение данных на проводе, т. Е. Ваши пакеты / PDU данных изложены точно так, как определено в спецификациях DIS

• Опирается на лучшие усилия (т.е. протокол UDP, вещание)

• Объекты должны сердцебиение на определенные промежутки времени (по умолчанию: 5 секунд), чтобы уведомить всех остальных, что все еще является частью упражнений

• Нет центрального сервера, управляющего различными приложениями, присоединились к упражнению

• Приложения моделирования могут присоединиться к моделированию в любое время, оставить в любое время

HLA

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

• Все федераты должны присоединиться и оставить симуляцию, пройдя через RTI

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

• HLA Federates публикуют данные в соответствии с FOM (модель объекта Федерации), которая определяет, какие данные в симуляции представляют. Это позволяет людям создавать новые FOMs, которые определяют новые типы объектов и взаимодействия, в отличие от DIS, где добавление новых типов данных PDU Data проходит через комитет (SISO). Например, большинство симуляций, работающих под HLA, используют RPR FOM, что в значительной степени отражает стандартные объекты и взаимодействия DIS.

• HLA добавляет дополнительные функции DIS не поддерживают, такие как управление распределением данных (DDM), в котором федераты уведомляют RTI, что они заинтересованы только в определенных типах данных.

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

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

Можно ли разместить HLA и наоборот?

Благодаря этим фундаментальным различиям следует ясно, что Dis и HLA не могут размещать друг друга.

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

Для еще дальнейшего чтения:

• http://www.mak.com/products/standards.php.
• http://www.siaa.asn.au/get/2395379411.pdf.
• http://ddss.ll.mit.edu/ddss.web/96.14.103.rti.introduction.html.

Answer 2

Вот некоторая арендоданная история в отношении HLA.

Дизайн HLA на самом деле основывается на том, что называется протоколом моделирования совокупности (ALLSP), который был приверен в начале 90-х годов теми же митрами, которые разработали HLA. ALLSP был разработан для связывания широкомасштабных конструктивных симуляций, используемых для корпорации / дивизиона. Требования к взаимодействию ALSP включали большее количество объектов, консервативное время Snchronization и обмен мероприятиями моделирования. Мы не могли позволить себе периодически вещать обновления сущностей, как это привело бы проблемы масштабируемости.

В мои более поздние годы участия мы достигли целых 1 миллиона объектов битвы на одного из участия в ULCHI Focus Lens. Фундаментальное различие между HLA и DIS является то, что HLA предназначена для обработки конструктивных крупномасштабных, переменных верности, консервативных временных симуляций, в то время как DIS родился из сетевой среды симулятора и ориентирован на ближневые симуляторы на уровне платформы.

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

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

Answer 3

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

Answer 4

Стандарт HLA 1516 определяет только API между симулятором и RTI. Не между RTI. Протокол, используемый для обмена данными между RTI, является проприетарным. Поэтому только RTI от того же самого поставщика или государственного агентства могут взаимодействовать. Большой недостаток. Если вы используете другой RTI, вам понадобится «мост» для перевода между проприетарными протоколами. Это может быть дорого.

Answer 5

Одно следует помнить, если вы планируете мостить Dis и HLA, то вы, возможно, проиграете точность моделирования с обеих сторон в зависимости от того, как организован ваш FOM. Dis To RPR FOM простым, но там есть и другие пломы, которые могут хорошо отобраться до DIS. В некоторых ситуациях вы можете быть неспособны перевести поле PDU в атрибут объекта HLA или параметр взаимодействия (или наоборот). Вам придется использовать ваши лучшие суждения относительно того, какие значения по умолчанию использовать в этих ситуациях. Другие времена иерархия объекта HLA FOM может быть структурирована очень по-разному от DIS. В этом случае перевод может потребоваться объединение данных из нескольких DIS PDU для формирования одного сообщения HLA. Это означает, что вам придется писать код в мосту, чтобы сохранить некоторую форму состояния сообщения.

Кроме того, во время выполнения вы получите свои атрибуты HLA по частям. После обнаружения объекта вам придется дождаться, чтобы перевести экземпляр объекта, пока вы не получили достаточно атрибутов, чтобы правильно заполнить DIS PDU.

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

Если у вас есть покупка бюджета, мой совет будет пойти с MAK VR-Exchange.