Arquitectura de alto nivel

HLA 1.3 fue publicado en marzo de 1998 por DMSO. Consta de:

• Departamento de Defensa de los Estados Unidos, Versión 1.3 del Reglamento
• Departamento de Defensa de los Estados Unidos, Especificación de la interfaz de arquitectura de alto nivel, versión 1.3
• Departamento de Defensa de los Estados Unidos, Plantilla de modelo de objetos de arquitectura de alto nivel, versión 1.3

El Departamento de Defensa de EE. UU. también publicó interpretaciones para HLA 1.3:

• Departamento de Defensa de los Estados Unidos, Interpretaciones de la Especificación de Interfaz de Arquitectura de Alto Nivel, Versión 1.3, Edición 3

La norma HLA IEEE 1516-2000 fue publicada en el año 2000 por el IEEE. Consta de:

• IEEE Std 1516–2000 – Norma para la arquitectura de alto nivel de modelado y simulación – Marco y reglas
• IEEE Std 1516.1–2000 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de interfaz federada
• Erratas de la norma IEEE 1516.1–2000 (16 de octubre de 2003)
• IEEE 1516.2-2000 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de la plantilla de modelo de objetos (OMT)

Las principales mejoras de la norma IEEE 1516-2000 incluyeron un FOM basado en XML con especificaciones detalladas del tipo de datos, así como un diseño DDM mejorado.

La norma IEEE 1516-2000 también se complementó con un proceso de desarrollo recomendado, así como con un proceso de verificación, validación y acreditación (VV&A) recomendado:

• IEEE 1516.3-2003 – Práctica recomendada para el proceso de desarrollo y ejecución de federaciones de arquitectura de alto nivel (FEDEP). Esta norma se convertiría más tarde en la norma IEEE Std 1730-2010, Proceso de ingeniería y ejecución de simulación distribuida ( DSEEP ).
• IEEE 1516.4-2007 – Práctica recomendada para la verificación, validación y acreditación de una federación: una superposición al proceso de desarrollo y ejecución de la arquitectura de alto nivel de la federación.

Pronto se descubrió que el estándar 1516-2000 tenía API que eran ligeramente diferentes para cada implementación de RTI. SISO produjo un estándar con API alternativas, compatibles con enlace dinámico (DLC) para C++ y Java:

• SISO-STD-004.1-2004: Estándar para la API HLA compatible con enlace dinámico. Estándar para la especificación de la interfaz HLA (versión IEEE 1516.1).
• SISO-STD-004-2004: Estándar para la API HLA compatible con enlace dinámico. Estándar para la especificación de la interfaz HLA (v1.3)

Posteriormente, las API de DLC se integraron en el estándar principal.

El estándar IEEE 1516-2010 fue publicado en agosto de 2010 por IEEE y se conoce comúnmente como HLA Evolved. ^{[ 7 ]} Consta de:

• IEEE 1516–2010 – Estándar para la arquitectura de alto nivel de modelado y simulación – Marco y reglas, ^{[ 8 ]}
• IEEE 1516.1–2010 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de interfaz federada, ^{[ 9 ]}
• IEEE 1516.2-2010 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de la plantilla de modelo de objetos (OMT), ^{[ 10 ]}

Las principales mejoras en IEEE 1516-2010 incluyen FOM modulares, ^{[ 11 ]} la incorporación de las API DLC en C++ y Java, una API de servicios web ^{[ 12 ]} y tolerancia a fallos. ^{[ 13 ]}

Las partes legibles por máquina de esta versión de HLA, como los esquemas XML, las API de C++, Java y WSDL , así como los ejemplos de FOM/SOM, se pueden descargar desde el área de descargas de IEEE 1516 del sitio web de IEEE . Los textos completos de los estándares están disponibles sin costo para los miembros de SISO o se pueden adquirir en la tienda de IEEE .

La norma IEEE 1516-2025 (HLA 4) fue aprobada por IEEE en febrero de 2025 y publicada en agosto de 2025. ^{[ 14 ]} Consta de:

• IEEE 1516–2025 – Estándar para la arquitectura de alto nivel de modelado y simulación – Marco y reglas ^{[ 4 ]}
• IEEE 1516.1–2025 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de interfaz federada ^{[ 5 ]}
• IEEE 1516.2-2025 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de la plantilla de modelo de objetos (OMT) ^{[ 6 ]}

HLA 4 ofrece mayor seguridad, escalabilidad, extensibilidad, compatibilidad con la nube y los contenedores, y soporte integral durante todo el ciclo de vida.

Las partes legibles por máquina de HLA 4, como los esquemas XML, las API de C++, Java y el protocolo Federate, así como los ejemplos de FOM/SOM, se pueden descargar desde la página IEEE 1516.1-2025 del sitio web de IEEE .

• Infraestructura de tiempo de ejecución (RTI) : Software que proporciona un conjunto estandarizado de servicios, tal como se especifica en la Especificación de interfaz federada HLA. Existen siete grupos de servicios.
• Federado : Un sistema, como una simulación, una herramienta o una interfaz para sistemas en funcionamiento, que se conecta a la RTI. Ejemplos de herramientas son los registradores de datos y las herramientas de gestión. Un federado utiliza los servicios de la RTI para intercambiar datos y sincronizarse con otros federados.
• Federación : Un conjunto de federados que se conectan a la misma RTI junto con un FOM común.
• Ejecución de federación : Una sesión en la que un conjunto de federados se ejecutan juntos en una federación con un objetivo específico, utilizando el mismo RTI y FOM.
• Modelo de Objetos de Federación (FOM) : Documento que especifica clases de objetos, clases de interacción, tipos de datos y datos adicionales utilizados para el intercambio de información en una federación. Un FOM es un archivo XML que sigue el formato de la Plantilla del Modelo de Objetos HLA y el Esquema XML asociado. Se utilizan diferentes FOM para el intercambio de datos en distintos dominios de aplicación. Existen FOM estandarizados, denominados FOM de referencia, que se utilizan habitualmente como punto de partida para el desarrollo de FOM. Un FOM puede desarrollarse y ampliarse de forma modular mediante módulos FOM.
• Modelo de Objetos de Simulación (SOM) : Documento que especifica las clases de objetos, las clases de interacción, los tipos de datos y los datos adicionales que una simulación publica o a los que se suscribe en una federación. Un SOM también es un archivo XML que sigue el formato de la plantilla del modelo de objetos HLA y el esquema XML asociado. Los SOM se pueden desarrollar y ampliar de forma modular mediante módulos SOM.
• Objeto : Los objetos se utilizan para representar datos que persisten durante un período de tiempo y que poseen atributos actualizables. Se definen en el FOM/SOM mediante una clase de objeto.
• Interacción : Las interacciones se utilizan para representar eventos instantáneos con parámetros. Una interacción enviada no se puede actualizar (a diferencia de las clases de objetos). Se definen en el FOM/SOM mediante una clase de interacción.
• Tipos de datos : La representación e interpretación de los datos de atributos y parámetros se especifica en el FOM/SOM mediante tipos de datos HLA.
• Publicar : Un federado que publica una clase de objeto con un conjunto de atributos puede registrar y eliminar instancias de esa clase de objeto y actualizar sus valores de atributos. Un federado que publica una clase de interacción puede enviar interacciones de esa clase de interacción, junto con los valores de los parámetros asociados.
• Suscripción : Un federado que se suscribe a una clase de objeto con un conjunto de atributos detectará los registros y eliminaciones de instancias de esa clase de objeto y recibirá actualizaciones de los atributos suscritos. Un federado que se suscribe a una clase de interacción recibirá las interacciones de esa clase de interacción, junto con los valores de los parámetros asociados.

El propósito de los servicios de gestión de la federación, descritos en el capítulo 4 de la especificación de la interfaz HLA, ^{[ 5 ]} es gestionar las ejecuciones de la federación, así como las operaciones de toda la federación, como los puntos de sincronización y el guardado/restauración.

Un conjunto de servicios de gestión de federación administra la conexión con RTI, la ejecución de la federación y el conjunto de federados unidos. Los servicios clave son:

• Conectar y desconectar de RTI
• CreateFederationExecution y DestroyFederationExecution se utilizan para crear y destruir una ejecución de federación.
• JoinFederationExecution y ResignFederationExecution son funciones que utiliza un federado para unirse y renunciar a una ejecución de federación.
• ConnectionLost, que es utilizado por RTI para informar a un federado que ha perdido su conexión con la ejecución de la federación debido a un fallo.
• ListFederationExecutions se utiliza para recuperar una lista de ejecuciones de federación disponibles para un RTI.

Otro conjunto de servicios se relaciona con los puntos de sincronización. Se trata de eventos que afectan a toda la federación, en los que todos los federados, o algunos seleccionados, deben completar una operación, como la inicialización de un escenario, antes de que la ejecución pueda continuar. Los servicios clave son:

• RegisterFederationSynchronizationPoint que se utiliza para registrar un punto de sincronización.
• AnnounceSynchronizationPoint, que es utilizado por el RTI para informar a los federados que se ha registrado un punto de sincronización.
• SynchronizationPointAchieved es utilizado por un federado para indicar que ha alcanzado un punto de sincronización.
• FederationSynchronized es un mensaje que utiliza RTI para informar a los federados de que la federación está sincronizada, es decir, que todos los federados han alcanzado el punto de sincronización.

Otro conjunto de servicios se relaciona con el guardado y la restauración de la ejecución de una federación. Una operación de guardado requiere que tanto la RTI como cada federado guarden su estado interno. Una operación de restauración requiere que tanto la RTI como cada federado restauren su estado interno. Los servicios clave son:

Ahorrar:

• RequestFederationSave que se utiliza para iniciar el guardado de una federación.
• InitiateFederateSave que utiliza el RTI para notificar a los federados que comiencen a guardar su estado.
• FederateSaveComplete, que será llamada por un federado cuando haya terminado de guardar su estado.
• FederationSaved, que es utilizado por RTI para notificar a los federados que la federación se ha guardado.

Restaurar:

• RequestFederationRestore que se utiliza para iniciar la restauración de una federación.
• InitiateFederateRestore que utiliza el RTI para notificar a los federados que comiencen a restaurar su estado.
• FederateRestoreComplete, que será llamada por un federado cuando haya completado la restauración de su estado.
• FederationRestored, que es utilizado por RTI para notificar a los federados que la federación se ha restaurado.

El propósito de los servicios de gestión de declaraciones, descritos en el capítulo 5 de la especificación de la interfaz HLA, ^{[ 5 ]} es permitir a los federados declarar qué información desean publicar (enviar) y a qué información desean suscribirse (recibir) en función de las clases de objetos e interacciones en el FOM. El RTI utiliza esta información para enrutar las actualizaciones e interacciones a los federados suscriptores. Para una clase de objeto, la publicación y la suscripción se realizan para un conjunto específico de atributos. Para las clases de interacción, se publica y se suscribe la interacción completa, incluidos todos los parámetros. Los servicios clave son:

• PublishObjectClassAttributes se utiliza para publicar un conjunto de atributos para una clase de objeto determinada.
• SubscribeObjectClassAttributes se utiliza para suscribirse a un conjunto de atributos para una clase de objeto determinada.
• PublishInteractionClass que se utiliza para publicar una clase de interacción que incluye todos los parámetros.
• SubscribeInteractionClass que se utiliza para suscribirse a una clase de interacción que incluye todos los parámetros.

El propósito de los servicios de administración de objetos, descritos en el capítulo 6 de la especificación de interfaz HLA, ^{[ 5 ]} es permitir que los federados compartan información sobre instancias de objetos e intercambien interacciones.

Los nombres de las instancias de objetos pueden reservarse o generarse automáticamente. Los federados pueden registrar instancias de objetos de clases específicas, que luego son descubiertas por los federados suscriptores. Los atributos de estas instancias de objetos pueden actualizarse. Estas actualizaciones se reflejarán en los federados suscriptores. Se pueden enviar interacciones. Estas interacciones se entregarán a los federados suscriptores. Los servicios clave son:

Objetos:

• ReserveObjectInstanceName que se utiliza para reservar un nombre que se utilizará para una instancia de objeto.
• RegisterObjectInstance se utiliza para registrar una instancia de objeto de una clase de objeto en particular, ya sea con un nombre reservado o con un nombre generado automáticamente.
• DiscoverObjectInstance es una función que utiliza RTI para notificar a los federados que se suscriben a una clase de objeto en particular que se ha registrado una nueva instancia de objeto.
• DeleteObjectInstance se utiliza para eliminar una instancia de objeto.
• RemoveObjectInstances que utiliza RTI para notificar a los federados que se ha eliminado una instancia de objeto.

Atributos:

• UpdateAttributeValues ​​se utiliza para proporcionar valores de atributos actualizados para una instancia de objeto.
• ReflectAttributeValues ​​es la función que utiliza RTI para notificar a los federados que se suscriben a atributos específicos sobre los valores actualizados.

Interacciones:

• SendInteraction se utiliza para enviar una interacción de una clase de interacción específica, incluyendo los valores de los parámetros.
• ReceiveInteraction es utilizado por RTI para entregar una interacción, incluidos los valores de los parámetros, a los federados que se suscriben a una clase de interacción particular.

El propósito de los servicios de gestión de propiedad, descritos en el capítulo 7 de la especificación de interfaz HLA, ^{[ 5 ]} es gestionar dinámicamente qué federado simula qué aspecto de una instancia de objeto. En HLA, solo un federado puede actualizar un atributo determinado de una instancia de objeto. Ese federado se considera el propietario del atributo. Un federado que registra una nueva instancia de objeto se convierte automáticamente en el propietario de todos los atributos que publica. En algunos casos, los atributos de una instancia de objeto pueden quedar sin propietario, es decir, sin ser propiedad de ningún federado.

La gestión de la propiedad proporciona servicios para transferir la propiedad de uno o varios atributos en tiempo de ejecución, lo que puede incluir que un federado se deshaga del atributo y otro lo adquiera. Existen dos patrones principales: "pull", iniciado por el federado adquirente, y "push", iniciado por el federado que se deshace del atributo.

Los servicios clave para iniciar la propiedad "por demanda" son:

• AttributeOwnershipAcquisitionIfAvailable, que es utilizado por un federado que desea adquirir la propiedad de atributos que no son propiedad de nadie.
• Adquisición de propiedad de atributos, que es utilizada por un federado que desea solicitar la propiedad de un atributo potencialmente poseído.

Los servicios clave para iniciar la propiedad mediante "empuje" son:

• AttributeOwnershipDivestitureIfWanted, que es utilizado por un federado que desea desprenderse de atributos solo si hay algún otro federado que esté listo para adquirir la propiedad de estos atributos.
• NegotiatedAttributeOwnershipDivestiture, que es similar pero también puede hacer que el RTI intente encontrar un nuevo propietario.
• UnconditionalAttributeOwnershipDivestiture, que es utilizada por un federado que desea renunciar a la propiedad, incluso si no se puede encontrar un nuevo propietario.

Todas las instancias de objeto tienen un atributo predefinido llamado HLAPrivilegeToDeleteObject. Solo el propietario de este atributo para una instancia de objeto puede eliminarla. La propiedad de este atributo se puede transferir en tiempo de ejecución mediante las operaciones descritas anteriormente.

El intercambio de información en una federación HLA se realiza en tiempo real con entrega inmediata (orden de recepción, RO) de mensajes, a menos que se haya habilitado la administración del tiempo HLA. El propósito de la administración del tiempo HLA, descrita en el capítulo 8 de la especificación de la interfaz HLA, ^{[ 5 ]} es garantizar la causalidad y un intercambio correcto y consistente de mensajes con marca de tiempo (actualizaciones e interacciones) en orden de marca de tiempo (TSO), independientemente de si la federación se ejecuta en tiempo real, más rápido que el tiempo real, más lento que el tiempo real o lo más rápido posible.

Algunos conceptos importantes en la gestión del tiempo de HLA son:

Tiempo lógico : Un eje de tiempo en HLA, que comienza en cero. El tiempo lógico se utiliza para las marcas de tiempo y las operaciones de gestión del tiempo. El eje de tiempo lógico se puede asignar al tiempo del escenario de la federación. Un ejemplo de dicha asignación es que cero represente el tiempo del escenario 8:00 del 1 de enero de 1966 y que un incremento de uno represente un segundo del escenario.

Anticipación : Un intervalo de tiempo que especifica el momento más temprano en el futuro para el cual un federado producirá mensajes. Para un federado con un paso de tiempo fijo, este suele ser la duración de dicho paso.

Concedido : El RTI concede a un federado (permite avanzar) a un momento lógico específico cuando se han entregado todos los mensajes con marca de tiempo hasta ese momento. El federado puede entonces comenzar a calcular con seguridad los mensajes con una marca de tiempo futura. Esta marca de tiempo no puede ser anterior al momento concedido más el tiempo de anticipación del federado.

Avance : Cuando un federado ha terminado de producir datos para el tiempo asignado más el tiempo de anticipación, puede solicitar avanzar a un tiempo posterior. Esto implica que se compromete a no producir más mensajes con una marca de tiempo inferior al tiempo solicitado más el tiempo de anticipación. El federado se encuentra ahora en estado de avance.

Regulación del tiempo : Un federado que envía eventos con marca de tiempo se considera Regulador del tiempo, ya que el avance del tiempo por parte de otros federados puede estar regulado por esto.

Restricción de tiempo : Un federado que recibe eventos gestionados por tiempo se considera con restricción de tiempo, ya que la recepción de mensajes con marca de tiempo limita su avance temporal.

Los principios fundamentales de la gestión del tiempo de HLA son los siguientes:

• Cada entidad federada que regula el tiempo asigna una marca de tiempo a los mensajes (actualizaciones e interacciones) cuando se envían, lo que indica el momento del escenario en el que el mensaje es válido.
• El RTI gestiona la entrega de mensajes a los federados con restricciones de tiempo, y los mensajes de los federados que regulan el tiempo se entregan en el momento adecuado mediante una cola de orden de marcas de tiempo.
• Los miembros de la federación con limitaciones de tiempo solicitan permiso a la RTI para adelantar su tiempo.
• El RTI concede un adelanto de tiempo a los federados con restricciones de tiempo cuando está seguro de que el federado no puede recibir un mensaje con una marca de tiempo anterior a su fecha de recepción.

Ejemplo de anticipación, concedida y en avance:

1. Un federado utiliza un paso de tiempo fijo de 10 y tiene una anticipación de 10.
2. El RTI garantiza al federado un tiempo lógico de 50. De este modo, el RTI asegura que todos los mensajes con un intervalo de tiempo menor o igual a 50 se hayan entregado al federado.
3. El federado ahora tiene todos los datos necesarios para calcular y enviar correctamente los mensajes durante el tiempo concedido más el Lookahead, es decir, 60.
4. Cuando el federado haya enviado todos los mensajes con marca de tiempo 60, solicitará que se le asigne la marca de tiempo 60. De este modo, se compromete a no enviar ningún mensaje con una marca de tiempo inferior a 70.
5. El RTI entrega al federado todos los mensajes con una marca de tiempo menor o igual a 60. Luego, le otorga al federado el tiempo 60.
6. Etc.

Si al menos un miembro de la federación realiza un control de sincronización, es decir, correlaciona sus solicitudes de avance de tiempo con un reloj en tiempo real, la federación puede funcionar en tiempo real o en tiempo real escalado. Sin control de sincronización, la federación funcionará lo más rápido posible (por ejemplo, las federaciones que no requieren interacción humana durante la ejecución ni interfaces con sistemas que dependen de un reloj en tiempo real pueden funcionar tan rápido como lo permitan los recursos informáticos).

Los servicios clave incluyen:

• EnableTimeConstrained y EnableTimeRegulating que habilitan estos modos para un federado
• TimeAdvanceRequest mediante la cual un federado solicita ser adelantado a un tiempo lógico específico.
• TimeAdvancedGrant mediante el cual el RTI informa a un federado que se le concede hasta un tiempo lógico específico.
• EnableAsynchronousDelivery permite la entrega de mensajes de orden de recepción tanto cuando un federado se encuentra en estado concedido como en estado de avance.

Para la simulación basada en eventos, también es posible que un federado solicite avanzar al siguiente evento utilizando el siguiente servicio:

• NextMessageRequest, mediante la cual un federado solicita que se le adelante a la marca de tiempo del siguiente mensaje que debe entregarse al federado, o a un tiempo lógico especificado, el que tenga una marca de tiempo más baja.

Otro concepto importante es el Tiempo Lógico Máximo Disponible (GALT, por sus siglas en inglés). El tiempo máximo que se le puede asignar a cada federado depende del tiempo que se les haya asignado a los demás, así como de su anticipación. El GALT de un federado especifica hasta qué punto se le puede asignar tiempo sin tener que esperar a que se les asigne a los demás. Esto es particularmente interesante para un federado que se une tardíamente a una federación con gestión de tiempo.

Los servicios clave de GALT son:

• QueryGALT que devuelve el GALT para el federado que realiza la llamada.

Entre los servicios más avanzados se incluyen:

• FlushQueueRequest permite a un federado solicitar la entrega de todos los mensajes en cola con marca de tiempo, independientemente de cuán lejana sea su marca de tiempo en el futuro.
• Retractar permite a un federado solicitar la retractación de un mensaje ya enviado. Esto resulta útil en simulaciones optimistas.

El propósito de DDM, descrito en el capítulo 9 de la Especificación de Interfaz HLA, ^{[ 5 ]} es aumentar la escalabilidad de las federaciones mediante el filtrado adicional de los datos suscritos, más allá de las suscripciones de clase y atributo. ^{[ 15 ]} El filtrado puede basarse en valores continuos (como latitud y longitud) o en valores discretos (como la marca del automóvil).

Los conceptos clave de DDM son:

Dimensión : un intervalo con nombre (0..n) utilizado para el filtrado, con valores que comienzan en 0 y terminan en un límite superior n. Los datos en el dominio de simulación se asignan a una o más dimensiones. Por ejemplo, las dimensiones para el filtrado geográfico podrían ser LatitudeDimension y LongitudeDimension. Una dimensión para el filtrado basado en la marca del automóvil podría ser CarBrandDimension.

Función de normalización : una función que asigna valores de entrada a valores enteros para su uso en una dimensión. Por ejemplo, una función de normalización para la dimensión Latitud podría asignar un valor de latitud entre -90,0 y +90,0 a un entero en el rango 0-179. Una función de normalización para la dimensión Marca de automóvil podría asignar un conjunto de marcas de automóviles (Kia, Ford, BMW y Peugeot) a un entero en el rango 0-3.

Rango : un intervalo en una dimensión, especificado por un límite inferior (inclusive) y un límite superior (exclusivo).

Región : un conjunto de rangos, cada uno relacionado con una dimensión particular. En el ejemplo anterior, una región podría consistir en el rango (3..5) para LatitudeDimension, (55..65) para LongitudeDimension y (0..1) para CarBrandDimension. En tiempo de ejecución, se instancian realizaciones de región (objetos) para representar regiones. Los rangos de una región pueden modificarse con el tiempo.

Superposición de regiones : dos regiones se superponen si, para todas las dimensiones que tienen en común, sus rangos se superponen.

En tiempo de ejecución, un federado puede proporcionar regiones al suscribirse a atributos e interacciones de clases de objetos. Las regiones también se utilizan al enviar actualizaciones de atributos e interacciones. Cuando se utiliza DDM, las actualizaciones de atributos y las interacciones solo se entregarán si existe una superposición de regiones.

Los servicios clave para las regiones son:

• CreateRegion se utiliza para crear una región con un conjunto específico de dimensiones.
• DeleteRegion que se utiliza para eliminar una región.
• CommitRegionModifications se utiliza para cambiar los rangos de una dimensión para una región.

Los servicios clave para intercambiar actualizaciones de atributos con DDM son:

• RegisterObjectInstanceWithRegions se utiliza para registrar una instancia de objeto con regiones asociadas a sus atributos.
• AssociateRegionsForUpdates se utiliza para asociar regiones con atributos de una instancia de objeto.
• SubscribeObjectClassAttributesWithRegions se utiliza para suscribirse a atributos de objetos donde las regiones utilizadas para la suscripción se superponen con las regiones de los atributos.

Los servicios clave para intercambiar interacciones con DDM son:

• SubscribeInteractionClassWithRegions se utiliza para suscribirse a interacciones donde las regiones utilizadas para la suscripción se superponen con las regiones de las interacciones.
• SendInteractionsWithRegions se utiliza para enviar interacciones con regiones asociadas.

Los Servicios de Soporte HLA, descritos en el capítulo 10 de la Especificación de Interfaz HLA, ^{[ 5 ]} proporcionan una serie de servicios de soporte. Estos incluyen:

• Obtención de identificadores (referencias) que se utilizarán en las llamadas de servicio anteriores.
• Configurar varios parámetros de ejecución, en particular para los avisos (notificaciones).
• Controlar la entrega de las devoluciones de llamada.

El propósito del Modelo de Objetos de Gestión (MOM), descrito en el capítulo 11 de la Especificación de Interfaz HLA, ^{[ 5 ]} es proporcionar servicios para la gestión de una federación. Esto se realiza mediante el uso de las clases de objetos e interacción del MOM. Los objetos del MOM se definen en un módulo FOM especial llamado MIM, que es cargado automáticamente por la RTI. Las características clave del MOM incluyen:

• Enumerar e inspeccionar las propiedades de los federados.
• Inspeccione las propiedades de la federación.
• Obtenga el contenido del FOM actual y de los módulos FOM.
• Inspeccione el estado de la gestión del tiempo.
• Inspeccionar y modificar las publicaciones y suscripciones de los federados.
• Examine ciertas cifras de rendimiento.
• Inspeccione qué entidad federada llama a qué servicios HLA.
• Inspeccione el estado de los puntos de sincronización.

El objetivo de la tabla de identificación es proporcionar metadatos sobre el modelo, para facilitar la reutilización del FOM/SOM o de los federados.

Se especifican los siguientes campos:

• General: Nombre, Tipo (FOM/SOM), Versión, Fecha de modificación, Clasificación de seguridad, Restricción de lanzamiento, Propósito, Dominio de aplicación, Descripción, Limitación de uso e Historial de uso
• Palabras clave: Valores de las palabras clave y taxonomía utilizada
• Puntos de contacto (POC): Tipo (Autor principal/Colaborador/Proponente/Patrocinador/Autoridad de publicación/POC técnico), Nombre del POC, Organización del POC, Teléfono del POC, Correo electrónico del POC
• Referencias: Tipo (Documento de texto/Hoja de cálculo/Archivo PowerPoint/FOM independiente/FOM dependiente/Compuesto a partir de FOM), Identificación (nombre del documento o nombre del FOM)
• Otro
• Glifo (Icono)

La tabla de estructura de clases de objetos tiene como objetivo especificar la jerarquía de clases (subclase/superclase) de las clases de objetos que se utilizan para instanciar objetos en una federación HLA. Los atributos de las clases de objetos se heredan de las superclases a las subclases según esta jerarquía. La raíz del árbol de clases de objetos se denomina HLAobjectRoot. Un ejemplo de nombre completo de una clase de objeto es HLAobjectRoot.Car.ElectricCar.

Los siguientes campos se especifican para una clase de objeto en la jerarquía:

• Nombre
• Publicación (Publicar/Suscribirse/PublicarSuscribirse/Ninguna de las dos)

La tabla de atributos tiene como objetivo especificar los atributos disponibles para una clase de objeto determinada. Dado que los atributos se heredan, una clase de objeto tendrá la unión de todos los atributos definidos localmente en la clase o especificados en cualquier superclase, ya sea directa o indirecta.

Los siguientes campos se especifican para un atributo.

• Nombre de la clase de objeto para la cual se define
• Nombre del atributo
• Tipo de dato, definido en la tabla de tipos de datos (ver más abajo).
• Tipo de actualización (estática/periódica/condicional/no aplicable)
• Condición de actualización
• D/A (Desinvertir/Adquirir/Sin transferencia/DesinvertirAdquirir): Indica si el atributo puede ser desinvertido o adquirido mediante los Servicios de propiedad de HLA.
• P/S (Publicar/Suscribir/Publicar/Suscribir/Ninguno): Indica si el atributo puede publicarse y/o suscribirse. En un SOM, esta información se refiere a la federación descrita; en un FOM, se refiere a toda la federación.
• Dimensiones disponibles
• Transporte (transporte confiable/de mejor esfuerzo/otros medios de transporte descritos en la tabla de transporte)
• Orden (Recepción/Marca de tiempo): Orden de entrega para actualizaciones de atributos.

La tabla de estructura de clases de interacción tiene como objetivo especificar la jerarquía de clases (subclase/superclase) de las clases de interacción que se utilizan para intercambiar interacciones en una federación HLA. Los parámetros de las clases de interacción se heredan de las superclases a las subclases según esta jerarquía. La raíz del árbol de clases de interacción se conoce como HLAinteractionRoot. Un ejemplo de nombre completo de una clase de interacción es HLAinteractionRoot.CarCommand.Start.

Los siguientes campos se especifican para una clase de interacción en la jerarquía:

• Nombre
• Publicación (Publicar/Suscribirse/PublicarSuscribirse/Ninguna de las dos)

La tabla de parámetros tiene como objetivo especificar los parámetros disponibles para una clase de interacción determinada. Dado que los parámetros se heredan, una clase de interacción tendrá la unión de todos los parámetros definidos localmente en la clase o especificados en cualquier superclase, ya sea directa o indirecta.

La finalidad de la tabla de dimensiones es especificar las dimensiones DDM, utilizadas para los atributos y las clases de interacción.

La finalidad de la tabla de representación del tiempo es especificar los tipos de datos utilizados por los servicios de gestión del tiempo.

Se puede proporcionar una etiqueta definida por el usuario al llamar a determinados servicios HLA. La tabla de etiquetas definidas por el usuario tiene como objetivo especificar los tipos de datos de estas etiquetas.

La finalidad de la tabla de sincronización es especificar los puntos de sincronización utilizados en una federación.

La tabla de tipos de transporte tiene como objetivo especificar los tipos de transporte disponibles. Existen dos tipos de transporte predefinidos: HLAreliable y HLAbestEffort.

La finalidad de la tabla de frecuencia de actualización es especificar las frecuencias máximas de actualización disponibles.

El comportamiento en tiempo de ejecución de la RTI se puede controlar mediante una serie de interruptores predefinidos. La tabla de interruptores sirve para proporcionar valores iniciales para estos interruptores. Algunos de ellos también se pueden actualizar durante la ejecución.

El propósito de las tablas de tipos de datos es proporcionar especificaciones de los tipos de datos utilizados para atributos, parámetros, dimensiones, representación temporal, etiquetas proporcionadas por el usuario y puntos de sincronización. Existen seis categorías de tipos de datos, cada una con un formato tabular independiente.

Tabla de tipos de datos simples

La tabla de tipos de datos simples tiene como objetivo describir elementos de datos escalares simples. El estándar HLA proporciona varios tipos de datos simples predefinidos: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time y HLAfloat64time. Es común incluir tipos de datos simples definidos por el usuario en un FOM.

Tabla de tipos de datos enumerados

La tabla de tipos de datos enumerados tiene como objetivo describir los elementos de datos que pueden tomar un conjunto finito y discreto de valores. El estándar incluye un tipo de dato enumerado predefinido: HLAboolean. Es común incluir tipos de datos enumerados definidos por el usuario en un FOM.

Tabla de tipos de datos de matriz

La tabla de tipos de datos enumerados tiene como objetivo describir matrices de elementos de datos (simples, enumerados, matrices, registros fijos o registros variantes). El estándar HLA proporciona varios tipos de datos simples predefinidos: HLAASCIIstring, HLAunicodeString, HLAopaqueData y HLAtoken. Es común incluir tipos de datos de matriz definidos por el usuario en un FOM.

Tabla de tipos de datos de registro fijo

La finalidad de la tabla de tipos de datos de registros fijos es describir los registros con un conjunto fijo de elementos de datos (simples, enumerados, matrices, registros fijos o registros variantes).

La finalidad de la tabla de notas es proporcionar anotaciones y descripciones adicionales de los elementos que aparecen en otras tablas.

El Modelo de Objeto Base (BOM), SISO-STD-003-2006, es un estándar relacionado de SISO para proporcionar una mejor reutilización y componibilidad para simulaciones HLA. Proporciona una forma de especificar modelos conceptuales y cómo mapearlos a un FOM HLA. ^{[ 18 ]}