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:
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.
Juntos, los componentes anteriores forman una Federación .
El estándar HLA consta de tres partes:
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:
El Departamento de Defensa de EE. UU. también publicó interpretaciones para HLA 1.3:
La norma HLA IEEE 1516-2000 fue publicada en 2000 por el IEEE y consta de:
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:
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:
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:
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:
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:
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:
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:
Restaurar:
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:
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:
Atributos:
Interacciones:
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:
Los servicios clave para iniciar la propiedad “push” son:
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:
Ejemplo de Lookahead, concedido y avanzando:
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:
Para la simulación basada en eventos, también es posible que un federado solicite pasar al siguiente evento utilizando el siguiente servicio:
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:
Los servicios más avanzados incluyen:
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:
Los servicios clave para intercambiar actualizaciones de atributos con DDM son:
Los servicios clave para intercambiar interacciones con DDM son:
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:
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:
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 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:
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:
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
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:
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]
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:
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.
{{cite journal}}: Requiere citar revista |journal=( ayuda )