Arquitectura de alto nivel

La arquitectura de alto nivel ( HLA ) es un estándar para simulación distribuida, que se utiliza al crear una simulación para un propósito más amplio mediante la combinación (federación) de varias simulaciones. ^[1] El estándar se desarrolló en la década de 1990 bajo el liderazgo del Departamento de Defensa de los EE. UU. ^[2] y luego pasó a convertirse en un estándar IEEE internacional abierto. Es un estándar recomendado dentro de la OTAN a través de STANAG 4603. ^[3] Hoy en día, el HLA se utiliza en varios dominios, incluidas la defensa y la seguridad y las aplicaciones civiles.

El objetivo de HLA es permitir la interoperabilidad y la reutilización. Las propiedades clave de HLA son:

• La capacidad de conectar simulaciones que se ejecutan en diferentes computadoras, localmente o ampliamente distribuidas, independientemente de su sistema operativo y lenguaje de implementación, en una Federación.
• Capacidad para especificar y utilizar modelos de datos de intercambio de información, modelos de objetos de federación (FOM), para diferentes dominios de aplicación.
• Servicios de intercambio de información mediante un mecanismo de publicación-suscripción, basado en el FOM, y con opciones de filtrado adicionales.
• Servicios para coordinar el intercambio de datos con marca de tiempo y tiempo lógico (simulación).
• Servicios de gestión para inspeccionar y ajustar el estado de una Federación.

HLA constituye la base para el desarrollo de FOM estandarizados y extensibles en diferentes comunidades, por ejemplo, en la industria aeroespacial y de defensa.

La arquitectura especifica los siguientes componentes.

• Una infraestructura de tiempo de ejecución (RTI) que proporciona un conjunto estandarizado de servicios a través de diferentes lenguajes de programación. Estos servicios incluyen intercambio de información, sincronización y gestión de federaciones.
• Federaciones que son sistemas de simulación individuales que utilizan servicios RTI.
• Un modelo de objetos de federación (FOM) que especifica las clases de objetos y las clases de interacción que se utilizan para intercambiar datos. El FOM puede describir información para cualquier dominio.

Juntos, los componentes anteriores forman una Federación .

El estándar HLA consta de tres partes:

1. IEEE Std 1516-2010 Marco y reglas , ^[4] que especifica diez reglas arquitectónicas que los componentes o toda la federación deben cumplir.
2. Especificación de interfaz federada IEEE Std 1516.1-2010 ^[5] , que especifica los servicios que debe proporcionar la RTI. Los servicios se proporcionan como API de C++ y Java, así como servicios web.
3. Especificación de plantilla de modelo de objeto IEEE Std 1516.2-2010 , ^[6] que especifica el formato que deben utilizar los modelos de objetos HLA, como el FOM.

La HLA se inició a principios de los años 1990 cuando la Dra. Anita K. Jones , Directora de Investigación e Ingeniería de Defensa dentro del Departamento de Defensa de los EE. UU., encomendó a la Oficina de Modelado y Simulación de Defensa (DMSO) la tarea de "garantizar la interoperabilidad y reutilización de los modelos y simulaciones de defensa". ^[1] En 1995, la DMSO formuló una visión para el modelado y la simulación y estableció un plan maestro de modelado y simulación, que incluía la Arquitectura de Alto Nivel.

Ya existían dos protocolos para la interoperabilidad de M&S: la Simulación Interactiva Distribuida (DIS), que se centra en la simulación a nivel de plataforma en tiempo real con un modelo de objeto fijo, y el Protocolo de Simulación a Nivel Agregado (ALSP), que se centra en la simulación de agregados con gestión del tiempo, gestión de la propiedad y modelos de objetos flexibles, denominados modelos de confederación. El propósito de HLA era proporcionar un estándar unificado que cumpliera con los requisitos de interoperabilidad de simulación de todos los componentes del Departamento de Defensa de los EE. UU. ^[2]

El desarrollo de HLA se basó en cuatro federaciones prototípicas: la Federación de Prototipos de Plataforma, la Federación de Prototipos de Entrenamiento Conjunto, la Federación de Prototipos de Análisis y la Federación de Prototipos de Ingeniería. La especificación de HLA se prototipó y se perfeccionó, hasta que finalmente se lanzó HLA 1.3. Para facilitar su uso fuera de la comunidad de defensa, HLA se convirtió en un estándar IEEE, mantenido por la Organización de Estándares de Interoperabilidad de Simulación (SISO). Para facilitar la migración para los usuarios de DIS, también se desarrolló un Modelo de Objeto de Federación correspondiente al modelo de objeto fijo de DIS como el Modelo de Referencia de Plataforma en Tiempo Real ( RPR FOM ).

Existen las siguientes versiones de HLA:

El DMSO publicó en marzo de 1998 el HLA 1.3. Está compuesto por:

• Departamento de Defensa de los Estados Unidos, Reglas versión 1.3
• Departamento de Defensa de EE. UU., Especificación de interfaz de arquitectura de alto nivel, versión 1.3
• Departamento de Defensa de EE. UU., 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 EE. UU., Interpretaciones de la especificación de interfaz de arquitectura de alto nivel, versión 1.3, versión 3

La norma HLA IEEE 1516-2000 fue publicada en 2000 por el IEEE y consta de:

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

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

El estándar IEEE 1516-2000 también se complementó con un proceso de desarrollo recomendado, así como un proceso 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 ejecución e ingeniería 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 como complemento al proceso de desarrollo y ejecución de la arquitectura de alto nivel de una 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 enlaces dinámicos (DLC) para C++ y Java:

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

Las API de DLC se fusionaron posteriormente con 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] Consiste en:

• IEEE 1516–2010 – Estándar para la arquitectura de alto nivel de modelado y simulación – Marco y reglas ^[4]
• IEEE 1516.1–2010 – Estándar para la arquitectura de alto nivel de modelado y simulación – Especificación de interfaz federada ^[5]
• IEEE 1516.2-2010 – Estándar para la modelización y simulación de arquitecturas de alto nivel – Especificación de plantillas de modelos de objetos (OMT) ^[6]

Las principales mejoras en IEEE 1516-2010 incluyen FOM modulares, ^[8] la incorporación de las API DLC en C++ y Java, una API de servicios web ^[9] y tolerancia a fallas. ^[10]

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 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 comprar en la tienda de IEEE.

El desarrollo de una nueva versión de HLA comenzó en enero de 2016 por SISO y actualmente está en curso.

El estándar HLA consta de tres partes:

• Marco y reglas , que especifica diez reglas arquitectónicas que las federaciones o toda la federación deben cumplir.
• Especificación de interfaz federada , que especifica los servicios que proporcionará la RTI. Los servicios se proporcionan como API de C++ y Java, así como servicios web.
• Especificación de plantilla de modelo de objeto que especifica el formato que deben utilizar los modelos de objetos HLA, como el FOM.

• Infraestructura en 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. Hay siete grupos de servicios.
• Federar : Un sistema, como una simulación, una herramienta o una interfaz para sistemas en vivo, que se conecta a la RTI. Algunos ejemplos de herramientas son los registradores de datos y las herramientas de gestión. Un federar utiliza los servicios de RTI para intercambiar datos y sincronizarse con otros federares.
• Federación : Un conjunto de federados que se conectan al mismo RTI junto con un FOM común.
• Ejecución de Federación : Una sesión, donde un conjunto de federados 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 que se utilizan para el intercambio de información en una federación. Un FOM es un archivo XML que sigue el formato de la plantilla de modelo de objetos HLA y el esquema XML asociado. Se utilizan diferentes FOM para intercambiar datos para diferentes dominios de aplicación. Existen FOM estandarizados, denominados FOM de referencia, que se utilizan comúnmente como punto de partida para el desarrollo de FOM. Un FOM se puede desarrollar y ampliar de forma modular utilizando módulos FOM.
• Modelo de objetos de simulación (SOM) : documento que especifica clases de objetos, clases de interacción, tipos de datos y datos adicionales que una simulación en particular publica y/o suscribe en una federación. Un SOM también es un archivo XML que sigue el formato de la plantilla de modelo de objetos HLA y el esquema XML asociado. Los SOM también se pueden desarrollar y ampliar de forma modular mediante módulos SOM.
• Objeto : Los objetos se utilizan para representar datos que son persistentes durante un período de tiempo y que tienen atributos que se pueden actualizar. 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 que se ha enviado 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 FOM/SOM utilizando tipos de datos HLA.
• Publicar : una federación que publica una clase de objeto con un conjunto de atributos puede registrar y eliminar instancias de esa clase de objeto y actualizar los valores de sus atributos. Una federación 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.
• Suscribirse : un federado que se suscribe a una clase de objeto con un conjunto de atributos descubrirá 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á interacciones de esa clase de interacción, junto con los valores de parámetros asociados.

Los servicios RTI se definen en la especificación de interfaz HLA y se agrupan en siete grupos de servicios. Además de estos servicios, el modelo de objetos de gestión (MOM) proporciona servicios que permiten inspeccionar y ajustar el estado de la federación mediante programación.

La mayoría de las RTI constan de un componente RTI central (CRC), que es un ejecutable, y componentes RTI locales (LRC), que son bibliotecas que utilizan los federados. Los servicios se proporcionan a través de una API de C++ o Java y también mediante servicios web. En las API de C++ y Java, los servicios se invocan mediante llamadas a una instancia de la clase RTI Ambassador. La RTI entrega información a un federado mediante devoluciones de llamadas, que se entregan mediante llamadas a una instancia de la clase Federate Ambassador. En la API de servicios web, definida mediante WSDL , las llamadas se realizan y las devoluciones de llamadas se obtienen mediante solicitudes y respuestas de servicios web.

Las descripciones de los grupos de servicios que aparecen a continuación se centran en los servicios clave. No se incluyen excepciones ni advertencias.

El propósito de los servicios de administración de la federación, descritos en el capítulo 4 de la especificación de interfaz HLA, ^[5] es administrar las ejecuciones de la federación, así como las operaciones de toda la federación, como los puntos de sincronización y guardar/restaurar.

Un conjunto de servicios de administración de federación administra la conexión a la RTI, la ejecución de la federación y el conjunto de federaciones unidas. Los servicios clave son:

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

Otro conjunto de servicios se relaciona con los puntos de sincronización. Se trata de eventos que se dan en toda la federación y en los que todas las federaciones, o solo algunas seleccionadas, 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 utiliza el RTI para informar a los federados que se ha registrado un punto de sincronización
• SynchronizationPointAchieved que utiliza un federado para indicar que ha alcanzado un punto de sincronización
• FederationSynchronized que es utilizado por el RTI para informar a los federados que la federación está sincronizada, es decir, todos los federados han alcanzado el punto de sincronización.

Otro conjunto de servicios se relaciona con el guardado y la restauración de una ejecución de federación. Una operación de guardado requiere que tanto la RTI como cada federación realicen un guardado de su estado interno. Una operación de restauración requiere que tanto la RTI como cada federación realicen una restauración de 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 deberá ser llamado por un federado cuando haya terminado de guardar su estado.
• FederationSaved que utiliza el RTI para notificar a los federados que la federación está guardada

Restaurar:

• RequestFederationRestore que se utiliza para iniciar una restauración de una federación
• InitiateFederateRestore que utiliza el RTI para notificar a los federados que comiencen a restaurar su estado
• FederateRestoreComplete que deberá ser llamado por un federado cuando haya terminado de restaurar su estado.
• FederationRestored que utiliza el 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 interfaz HLA ^[5] , es permitir que los federados declaren qué información desean publicar (enviar) y suscribirse (recibir) en función de las clases de objetos e interacciones en el FOM. La RTI utiliza esta información para enviar actualizaciones e interacciones a los federados suscriptores. Para una clase de objeto, la publicación y suscripción se realizan para un conjunto específico de atributos. Para las clases de interacción, se publica y suscribe toda la interacción, incluidos todos los parámetros. Los servicios clave son:

• PublishObjectClassAttributes que se utiliza para publicar un conjunto de atributos para una clase de objeto determinada.
• SubscribeObjectClassAttributes que 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 gestió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 instancias de objetos se pueden reservar o generar automáticamente. Los federados pueden registrar instancias de objetos de clases de objetos específicas, que luego son descubiertas por los federados suscriptores. Los atributos de estas instancias de objetos se pueden actualizar. 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 que se utiliza para registrar una instancia de objeto de una clase de objeto particular, ya sea con un nombre reservado o un nombre generado automáticamente.
• DiscoverObjectInstance que utiliza el RTI para notificar a los federados que se suscriben a una clase de objeto particular que se ha registrado una nueva instancia de objeto.
• DeleteObjectInstance que 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 ​​que se utiliza para proporcionar valores de atributo actualizados para una instancia de objeto
• ReflectAttributeValues ​​que utiliza RTI para notificar a los federados que se suscriben a atributos particulares sobre valores actualizados.

Interacciones:

• SendInteraction que se utiliza para enviar una interacción de una clase de interacción particular, incluidos los valores de los parámetros.
• ReceiveInteraction que utiliza el 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 administración de propiedad, descritos en el capítulo 7 de la especificación de interfaz HLA ^[5] , es administrar dinámicamente qué federación simula qué aspecto de una instancia de objeto. En HLA, solo una federación puede actualizar un atributo determinado de una instancia de objeto determinada. Esa federación se considera el propietario del atributo. Una federación que registre una nueva instancia de objeto será automáticamente el propietario de todos los atributos que publique. En algunos casos, los atributos de una instancia de objeto pueden dejar de tener propietario, es decir, no ser propiedad de ninguna federación.

La gestión de propiedad proporciona servicios para transferir la propiedad de uno o varios atributos en tiempo de ejecución, lo que puede incluir que un federado desinvierta el atributo y que otro federado adquiera el atributo. Hay dos patrones principales: "pull", que son iniciados por el federado adquirente, y "push", que son iniciados por el federado que desinvierte.

Los servicios clave para iniciar la propiedad “pull” son:

• AttributeOwnershipAcquisitionIfAvailable que es utilizado por un federado que desea adquirir la propiedad de atributos sin propietario.
• AttributeOwnershipAcquisition que utiliza un federado que desea solicitar la propiedad de un atributo potencialmente poseído

Los servicios clave para iniciar la propiedad “push” son:

• AttributeOwnershipDivestitureIfWanted que es utilizado por un federado que desea desprenderse de atributos solo si hay otro federado que esté listo para adquirir la propiedad de estos atributos.
• NegotiatedAttributeOwnershipDesinversion, que es similar pero también puede provocar que el RTI intente encontrar un nuevo propietario.
• Desinversión de propiedad de atributo incondicional, 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 eliminar la instancia de objeto. La propiedad de este atributo se puede transferir en tiempo de ejecución mediante las operaciones anteriores.

El intercambio de información en una federación HLA se lleva a cabo en tiempo real con entrega inmediata (Orden de recepción, RO) de mensajes, a menos que se haya habilitado la Gestión de tiempo HLA. El propósito de la Gestión de tiempo HLA, descrita en el capítulo 8 de la Especificación de interfaz HLA, ^[5] es garantizar la causalidad y un intercambio correcto y consistente de mensajes con sello de tiempo (actualizaciones e interacciones) en Orden de sello de tiempo (TSO), sin importar 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 HLA son:

Tiempo lógico : 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 este tipo de asignación es dejar que cero represente el tiempo del escenario 8:00 del 1 de enero de 1066 y dejar que un incremento de uno represente un segundo del escenario.

Lookahead : intervalo de tiempo que especifica el tiempo mínimo en el futuro en el que una federación producirá mensajes. Para una federación con un paso de tiempo fijo, normalmente es la duración del paso de tiempo.

Concedido : el RTI concede (permite) a un federado avanzar hasta un tiempo lógico determinado cuando se han entregado todos los mensajes con marca de tiempo hasta ese momento. El federado puede entonces comenzar a calcular de forma segura los mensajes con una marca de tiempo en el futuro. Esta marca de tiempo no puede ser anterior al tiempo concedido más la previsión del federado.

Avanzando : cuando un federado ha terminado de producir datos para el tiempo concedido más el tiempo de anticipación, puede solicitar que se lo avance a un tiempo posterior, lo que también significa que promete no producir más mensajes con una marca de tiempo menor que el tiempo solicitado más el tiempo de anticipación. El federado ahora se encuentra en estado de avance.

Regulación de Tiempo : Un federado que envía eventos con sello de tiempo se considera Regulador de Tiempo ya que el avance de tiempo de otros federados puede ser regulado por esto.

Con restricciones de tiempo : una federación que recibe eventos administrados en el tiempo se considera con restricciones de tiempo ya que la recepción de mensajes con marcas de tiempo restringe su avance en el tiempo.

Los principios fundamentales de la Gestión del Tiempo de HLA son los siguientes:

• Cada federación reguladora del tiempo asigna una marca de tiempo a los mensajes (actualizaciones e interacciones) cuando se envían, indicando el tiempo del escenario en el que el mensaje es válido.
• La RTI administra la entrega de mensajes a federaciones con restricciones de tiempo, y los mensajes de las federaciones con restricciones de tiempo se entregan en el momento apropiado mediante una cola de orden de marca de tiempo.
• Los federados con limitaciones de tiempo solicitan permiso al RTI para adelantar su tiempo.
• La RTI otorga un adelanto de tiempo a un federado con restricciones de tiempo cuando está seguro de que el federado no puede recibir un mensaje con una marca de tiempo en su pasado.

Ejemplo de Lookahead, concedido y avanzando:

1. Una federación utiliza un paso de tiempo fijo de 10 y tiene un Lookahead de 10.
2. El RTI concede al federado el tiempo lógico 50. De esta forma, el RTI garantiza que todos los mensajes con un paso 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 para el tiempo concedido más Lookahead, es decir 60.
4. Cuando el federado ha enviado todos los mensajes con marca de tiempo 60, solicita que se lo avance al 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 todos los mensajes con una marca de tiempo menor o igual a 60 al federado. Luego le otorga al federado el tiempo 60.
6. Etc.

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

Los servicios clave incluyen:

• EnableTimeConstrained y EnableTimeRegulating que habilitan estos modos para una federación
• TimeAdvanceRequest mediante el cual un federado solicita avanzar a un tiempo lógico específico
• TimeAdvancedGrant mediante el cual el RTI informa a un federado que se le concede un tiempo lógico específico.
• EnableAsynchronousDelivery que habilita la entrega de mensajes de orden de recepción tanto cuando un federado está en estado otorgado como en estado avanzado.

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

• NextMessageRequest mediante el cual un federado solicita que se le avance a la marca de tiempo del próximo mensaje que debe entregarse al federado, o a una hora lógica especificada, lo que tenga una marca de tiempo menor.

Otro concepto importante es el tiempo lógico más grande disponible (GALT). El tiempo más grande que se le puede otorgar a cada federación depende del tiempo que se le haya otorgado a otras federaciones, así como de su anticipación. El GALT de una federación especifica hasta qué punto se le puede otorgar una federación, sin tener que esperar a que se le otorgue la misma a otras federaciones. Esto es particularmente interesante para una federación que se une tarde a una federación administrada por tiempo.

Los servicios clave para GALT son:

• ConsultaGALT que devuelve el GALT para el federado que llama.

Los servicios más avanzados incluyen:

• FlushQueueRequest mediante el cual un federado puede solicitar la entrega de todos los mensajes en cola con marca de tiempo, sin importar qué tan lejos en el futuro esté su marca de tiempo.
• Retractación mediante la cual un federado puede solicitar que se retracte un mensaje ya enviado. Esto resulta útil en la simulación optimista.

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 realizando un filtrado adicional de datos suscritos más allá de las suscripciones de clase y atributo. ^[11] El filtrado puede basarse en valores continuos (como latitud y longitud) o valores discretos (como la marca del automóvil).

Los conceptos clave del DDM son:

Dimensión : un intervalo con nombre (0..n) utilizado para filtrar, con valores que comienzan con 0 y terminan con 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 : función que asigna valores de entrada a valores enteros que se utilizarán en una dimensión. Un ejemplo es que una función de normalización para LatitudeDimension podría asignar un valor de latitud que va desde -90,0 a +90,0 a un entero en el rango de 0 a 179. Una función de normalización para CarBrandDimension podría asignar un conjunto de marcas de automóviles Kia, Ford, BMW y Peugeot a un entero en el rango de 0 a 3.

Rango : un intervalo en una dimensión, especificado por un límite inferior (inclusivo) 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 constar del rango (3..5) para LatitudeDimension (55..65) para LongitudeDimension y (0..1) para CarBrandDimension. En tiempo de ejecución, se crean instancias de realizaciones de región (objetos) para representar regiones. Los rangos de una región se pueden modificar 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, una federación puede proporcionar regiones al suscribirse a interacciones y atributos de clase de objeto. Las regiones también se utilizan al enviar interacciones y actualizaciones de atributos. Cuando se utiliza DDM, las interacciones y actualizaciones de atributos solo se entregarán si hay una superposición de regiones.

Los servicios clave para las regiones son:

• CreateRegion que se utiliza para crear una región con un conjunto específico de dimensiones.
• DeleteRegion que se utiliza para eliminar una región.
• CommitRegionModifications que 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 que se utiliza para registrar una instancia de objeto con regiones asociadas a sus atributos.
• AssociateRegionsForUpdates que se utiliza para asociar regiones con atributos de una instancia de objeto.
• SubscribeObjectClassAttributesWithRegions que 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 que se utiliza para suscribirse a interacciones donde las regiones utilizadas para la suscripción se superponen con las regiones de las interacciones.
• SendInteractionsWithRegions que se utiliza para enviar interacciones con regiones asociadas.

Los servicios de soporte de HLA, descritos en el capítulo 10 de la especificación de interfaz de HLA ^[5] , proporcionan una serie de servicios de soporte, entre los que se incluyen:

• Obtener identificadores (referencias) que se utilizarán en las llamadas de servicio anteriores.
• Configuración de varios interruptores de tiempo de ejecución, en particular para avisos (notificaciones).
• Controlar la entrega de devoluciones de llamadas.

El objetivo del modelo de objetos de gestión, descrito en el capítulo 11 de la especificación de interfaz HLA ^[5] , es proporcionar servicios para gestionar una federación. Esto se lleva a cabo utilizando las clases de interacción y objetos MOM. Los objetos MOM se definen en un módulo FOM especial llamado MIM, que la RTI carga automáticamente. Las características clave de MOM incluyen:

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

El OMT es una plantilla que se utiliza para describir los modelos de objetos de federación (FOM) y los modelos de objetos de simulación (SOM). Los FOM y los SOM se pueden representar en formato tabular o mediante XML. Este último formato se utiliza cuando se carga un FOM en la RTI.

En versiones anteriores de HLA, los FOM eran monolíticos, pero la versión actual del estándar admite FOM modulares, es decir, se pueden proporcionar al RTI varios módulos que cubren diferentes aspectos del intercambio de información.

En el estándar se proporcionan una serie de clases, tipos de datos, dimensiones y tipos de transporte predefinidos. Estos se proporcionan en el módulo FOM HLAstandardMIM.xml. Los conceptos predefinidos tienen el prefijo HLA, por ejemplo, HLAobjectRoot y HLAunicodeString.

Hay tres esquemas XML diferentes para el OMT:

• El esquema XML OMT DIF, que verifica que un documento OMT sigue el formato OMT básico, pero no que esté completo y tenga integridad referencial.
• El esquema XML de OMT FDD, que verifica que un documento OMT contenga suficiente información para que sea útil para una RTI. Tenga en cuenta que este esquema se proporciona en la Especificación de interfaz.
• El esquema de conformidad OMT que verifica que un documento OMT está completo y tiene integridad referencial.

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

Se especifican los siguientes campos:

• General: Nombre, Tipo (FOM/SOM), Versión, Fecha de modificación, Clasificación de seguridad, Restricción de publicación, 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
• Punto 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 de PowerPoint/FOM independiente/FOM dependiente/Compuesto a partir de FOM), Identificación (nombre del documento o nombre del FOM)
• Otro
• Glifo (icono)

El propósito de la tabla de estructura de clases de objetos es 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 clase de objeto se heredan de las superclases a las subclases en función de esta jerarquía. La raíz del árbol de clases de objetos se conoce como HLAobjectRoot. Un ejemplo de un 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)

El propósito de la tabla de atributos es especificar los atributos que están 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 que se definen localmente en la clase de objeto o se especifican en cualquier superclase directa o indirecta.

Los siguientes campos se especifican para un atributo

• Nombre de la clase del objeto para el que está definido
• Nombre del atributo
• Tipo de datos, definido en la tabla de tipos de datos (ver más abajo)
• Tipo de actualización (estática/periódica/condicional/NA)
• Condición de actualización
• D/A (Desinvertir/Adquirir/No Transferir/Desinvertir-Adquirir): si el atributo se puede desinvertir o adquirir utilizando los Servicios de propiedad de HLA
• P/S (Publish/Subscribe/PublishSubscribe/Neither): si el atributo se puede publicar o suscribir. En un SOM, esta información se relaciona con la federación descrita, en un FOM se relaciona con toda la federación.
• Dimensiones disponibles
• Transporte (confiable/mejor esfuerzo/otros transportes descritos en la tabla de transporte)
• Orden (Recibir/Marca de tiempo): Orden de entrega para actualizaciones de atributos.

El propósito de la tabla de estructura de clases de interacción es 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 clase de interacción se heredan de las superclases a las subclases en función de esta jerarquía. La raíz del árbol de clases de interacción se conoce como HLAinteractionRoot. Un ejemplo de un 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)

El propósito de la tabla de parámetros es especificar los parámetros que están 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 que se definen localmente en la clase de interacción o se especifican en cualquier superclase directa o indirecta.

El propósito de la tabla de dimensiones es especificar las dimensiones DDM, utilizadas para atributos y clases de interacción.

El propósito 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 proporcionada por el usuario al llamar a determinados servicios HLA. El propósito de la tabla de etiquetas proporcionadas por el usuario es especificar los tipos de datos de estas etiquetas.

El propósito de la tabla de sincronización es especificar los puntos de sincronización utilizados en una federación.

El objetivo de la tabla de tipos de transporte es especificar los tipos de transporte disponibles. Hay dos tipos de transporte predefinidos: HLAreliable y HLAbestEffort.

El propósito de la tabla de tasas de actualización es especificar las tasas de actualización máximas disponibles.

El comportamiento en tiempo de ejecución del RTI se puede controlar mediante una serie de parámetros predefinidos. El objetivo de la tabla de parámetros es proporcionar valores iniciales para estos parámetros. Algunos de los parámetros también se pueden actualizar en tiempo de ejecución.

El objetivo 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, con un formato tabular independiente para cada una de ellas.

El propósito de la tabla de representación de datos básicos es proporcionar representaciones binarias para su uso en otras tablas. En el estándar HLA se proporcionan varios tipos de datos básicos predefinidos: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteger64LE, HLAfloat32LE, HLAfloat64LE, HLAoctetPairLE y HLAoctet. El conjunto de tipos de datos básicos no suele ampliarse con tipos de datos básicos definidos por el usuario.

El propósito de la tabla de tipos de datos simples es describir elementos de datos escalares simples. En el estándar HLA se proporcionan 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.

El propósito de la tabla de tipos de datos enumerados es describir los elementos de datos que pueden adoptar un conjunto de valores discretos finitos. En el estándar se proporciona un tipo de datos enumerado predefinido: HLAboolean. Es común incluir tipos de datos enumerados definidos por el usuario en un FOM.

El propósito de la tabla de tipos de datos enumerados es describir matrices de elementos de datos (simples, enumerados, matrices, registros fijos o registros variantes). En el estándar HLA se proporcionan 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.

El propósito de la tabla de tipos de datos de registros fijos es describir registros con un conjunto fijo de elementos de datos (simples, enumerados, matrices, registros fijos o registros variantes).

El propósito de la tabla de tipos de datos de registros de variantes es describir los registros que pueden contener diferentes conjuntos predefinidos de elementos de datos. Los diferentes conjuntos se denominan Alternativas. La alternativa que se aplica a un registro de variante determinado se indica mediante un elemento de datos denominado Discriminante.

El propósito de la tabla de notas es proporcionar anotaciones y descripciones adicionales de elementos en otras tablas.

Las reglas de la HLA describen las responsabilidades de las federaciones y de los federados que se unen a ellas. ^[12]

1. Las federaciones deberán tener un modelo de objetos de federación (FOM) HLA, documentado de acuerdo con la plantilla del modelo de objetos (OMT) HLA.
2. En una federación, toda la representación de objetos en el FOM debe estar en los federados, no en la infraestructura de tiempo de ejecución (RTI).
3. Durante la ejecución de una federación, todo el intercambio de datos FOM entre federados se realizará a través de RTI.
4. Durante la ejecución de una federación, los federados deberán interactuar con la infraestructura de tiempo de ejecución (RTI) de acuerdo con la especificación de la interfaz HLA.
5. Durante la ejecución de una federación, un atributo de una instancia de un objeto debe ser propiedad de un solo federado en un momento dado.
6. Los federados deberán tener un modelo de objeto de simulación HLA (SOM), documentado de acuerdo con la plantilla de modelo de objeto HLA (OMT).
7. Los federados podrán actualizar y/o reflejar cualquier atributo de los objetos en su SOM y enviar y/o recibir interacciones de objetos SOM externamente, según lo especificado en su SOM.
8. Los federados podrán transferir y/o aceptar la propiedad de un atributo dinámicamente durante una ejecución de federación, como se especifica en su SOM.
9. Los federados podrán variar las condiciones bajo las cuales proporcionan actualizaciones de atributos de objetos, según se especifica en su SOM.
10. Las federaciones podrán gestionar la hora local de manera que les permita coordinar el intercambio de datos con otros miembros de la federación.

El estándar IEEE 1516 ha sido revisado por el Grupo de Desarrollo de Productos HLA-Evolved de SISO y fue aprobado el 25 de marzo de 2010 por el Consejo de Actividades de Estándares de IEEE. El estándar IEEE 1516-2010 revisado incluye las interpretaciones estándar actuales del Departamento de Defensa y la API EDLC, una versión extendida de la API DLC de SISO. Otras mejoras importantes incluyen:

• Compatibilidad XML ampliada con FOM/SOM, como esquemas y extensibilidad
• Servicios de soporte de tolerancia a fallos
• Compatibilidad/API de servicios web (WSDL)
• FOM modulares
• Reducción de la tasa de actualización
• Ayudantes de codificación
• Soporte ampliado para transporte adicional (como QoS, IPv6,...)
• Representaciones de tiempo estandarizadas

Para garantizar la interacción adecuada entre simulaciones, se define una forma de probar la conformidad de la federación. Esto implica garantizar que cada clase e interacción enumerada en el SOM para una federación en particular se utilice de acuerdo con el uso descrito, "PublishSubscribe", "Publish", "Subscribe" o "None".

HLA (tanto en la versión actual IEEE 1516 como en su versión antecesora "1.3") es el tema del acuerdo de estandarización de la OTAN (STANAG 4603) para modelado y simulación: Estándares de arquitectura de modelado y simulación para interoperabilidad técnica: Arquitectura de alto nivel (HLA) . ^[13]

El modelo de objeto base (BOM), SISO-STD-003-2006, es un estándar relacionado de SISO que ofrece una mejor reutilización y capacidad de composición para las simulaciones HLA. Proporciona una manera de especificar modelos conceptuales y cómo mapearlos a un modelo de objeto base HLA. ^[14]

En lo que respecta a la industria de simulación y modelado distribuido (DM&S), la alternativa más utilizada al HLA para la simulación en tiempo real de plataformas militares es la simulación interactiva distribuida (DIS), IEEE 1278.1-2012, un protocolo de simulación. La mayoría de los proveedores de RTI de HLA también incluyen DIS en sus productos. En cuanto a las aplicaciones de middleware que más se asemejan a las características de HLA, como la función de publicación y suscripción (P&S), consulte el Servicio de distribución de datos (DDS), que comparte muchas de las mismas características pero tiene un protocolo abierto en la red para la interoperabilidad del sistema. ^[15]

HLA es un middleware orientado a mensajes que se define como un conjunto de servicios proporcionados por una API de C++ o Java . No existe un protocolo estandarizado en la red. Los participantes de una federación deben utilizar bibliotecas RTI del mismo proveedor y, por lo general, también de la misma versión, lo que en algunos casos se percibe como un inconveniente. ^[16] La mayoría de las herramientas actuales también proporcionan interconectividad a través de sockets.

• Lista de RTI comerciales y no comerciales
• Simulación por computadora
• Computación distribuida
• Organización de estándares de interoperabilidad de simulación

• El tutorial de HLA: un tutorial gratuito (PDF)

• Erratas de la norma IEEE para modelado y simulación (M&S) Arquitectura de alto nivel (HLA): Especificación de interfaz federada
• Departamento de Defensa (DoD) Interpretaciones de la serie de normas IEEE 1516-2000, versión 2 (1 de julio de 2003)