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

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

ДИС

• Стандарт определяет размещение данных в проводной сети, т. е. ваши PDU пакетов/данных размещаются точно так, как это определено в спецификациях DIS.

• Полагается на сетевые возможности с максимальной эффективностью (например, протокол UDP, широковещательная рассылка)

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

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

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

HLA

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

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

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

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

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

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

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

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

Из-за этих фундаментальных различий должно быть ясно, что DIS и HLA не могут размещать друг друга.

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

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

• http://www.mak.com/products/standards.php
• http://www.siaa.asn.au/get/2395379411.pdf
• http://dss.ll.mit.edu/dss.web/96.14.103.RTI.Introduction.html

Вот немного малоизвестной истории, касающейся HLA.

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

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

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

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

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

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

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

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

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

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