Arquitectura de alto nivel

Standard for distributed simulation

Este artículo trata sobre el estándar IEEE para simulación distribuida. Para otros usos, consulte Nivel alto y bajo .

La Arquitectura de alto nivel ( HLA ) es un estándar para la simulación distribuida, que se utiliza cuando se crea una simulación para un propósito mayor mediante la combinación (federación) de varias simulaciones. ^[1] El estándar se desarrolló en los años 90 bajo el liderazgo del Departamento de Defensa de EE. UU. ^[2] y luego se transformó para 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 aplicaciones de defensa y seguridad y civiles.

El propósito 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 sola 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 para el intercambio de información mediante un mecanismo de publicación-suscripción, basado en la FOM, y con opciones de filtrado adicionales.
• Servicios para coordinar el tiempo lógico (simulación) y el intercambio de datos con sello de tiempo.
• 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 ampliables en diferentes comunidades, por ejemplo, en la industria aeroespacial y de defensa.

La arquitectura especifica los siguientes componentes.

Componentes de una federación HLA

• Una infraestructura en tiempo de ejecución (RTI) que proporciona un conjunto estandarizado de servicios a través de diferentes lenguajes de programación. Estos servicios incluyen el intercambio de información, la sincronización y la gestión de la federación.
• Federados 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 utilizadas para intercambiar datos. La 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 Framework and Rules , ^[4] que especifica diez reglas arquitectónicas a las que deben adherirse los componentes o toda la federación.
2. IEEE Std 1516.1-2010 Especificación de interfaz federada , ^[5] que especifica los servicios que proporcionará el RTI. Los servicios se proporcionan como API de C ++ y Java, así como servicios web.
3. IEEE Std 1516.2-2010 Object Model Template Specification , ^[6] que especifica el formato que deben utilizar los modelos de objetos HLA, como el FOM.

Historia y versiones

El HLA se inició a principios de la década de 1990 cuando la Dra. Anita K. Jones , Directora de Investigación e Ingeniería de Defensa del Departamento de Defensa de EE. UU., Asignó a la Oficina de Simulación y Modelado de Defensa (DMSO) la tarea de “asegurar la interoperabilidad y la reutilización de los modelos de defensa y simulaciones ”. ^[1] En 1995, 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: Simulación interactiva distribuida (DIS), que se enfoca en la simulación de nivel de plataforma en tiempo real con un modelo de objeto fijo, y Protocolo de simulación de nivel agregado (ALSP) que se enfoca en la simulación de agregado con administración del tiempo, administración de propiedad y flexibilidad modelos de objetos, llamados 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 EE. UU. ^[2]

El desarrollo de HLA se basó en cuatro federaciones prototípicas: la Platform Prototype Federation, la Joint Training Protofederation, la Analysis Protofederation y la Engineering Prototype Federation. La especificación HLA se diseñó y perfeccionó hasta que finalmente se lanzó HLA 1.3. Para facilitar el uso fuera de la comunidad de defensa, HLA se transformó 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 objetos de federación correspondiente al modelo de objetos fijos de DIS como FOM de referencia de plataforma en tiempo real ( RPR FOM ).

Existen las siguientes versiones de HLA:

HLA 1.3

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

• Departamento de Defensa de EE. UU., 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

HLA 1516-2000

HLA IEEE 1516-2000 fue publicado en 2000 por IEEE. Consiste en:

• IEEE Std 1516-2000 - Estándar para modelado 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
• IEEE 1516.1–2000 Errata (2003-oct-16)
• 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 tipo 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 con un proceso VV&A recomendado:

• IEEE 1516.3-2003 - Práctica recomendada para el proceso de desarrollo y ejecución de la federación de arquitectura de alto nivel (FEDEP). Este estándar más tarde se convertiría en 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, una superposición al proceso de desarrollo y ejecución de la federación de arquitectura de alto nivel

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 de Java y C ++ compatibles con enlaces dinámicos (DLC):

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

Las API de DLC se fusionaron más tarde en el estándar principal.

HLA 1516-2010 (HLA evolucionado)

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 modelado y simulación de arquitectura de alto nivel - Marco y reglas ^[4]
• IEEE 1516.1–2010 - Estándar para modelado y simulación de arquitectura de alto nivel - Especificación de interfaz federada ^[5]
• IEEE 1516.2-2010 - Estándar para modelado y simulación de arquitectura de alto nivel - Especificación de plantilla de modelo de objeto (OMT) ^[6]

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

Las partes legibles por máquina de esta versión de HLA, como los esquemas XML, C ++, Java y las API WSDL , así como las muestras de FOM / SOM, se pueden descargar del área de descarga 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 comprar en la tienda IEEE .

HLA 1516-20XX (HLA 4)

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

Resumen técnico

El estándar HLA consta de tres partes:

• Marco y Reglas , que especifica diez reglas arquitectónicas a las que se adherirán las federaciones o toda la federación.
• Especificación de interfaz federada , que especifica los servicios que proporcionará el 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 objeto de HLA, como el FOM.

Terminología común de HLA

• Infraestructura en tiempo de ejecución (RTI) : software que proporciona un conjunto estandarizado de servicios, como se especifica en la Especificación de interfaz federada de HLA. Hay siete grupos de servicios.
• Federate : un sistema, como una simulación, una herramienta o una interfaz para sistemas activos, que se conecta al RTI. Algunos ejemplos de herramientas son los registradores de datos y las herramientas de gestión. Una federación utiliza los servicios de RTI para intercambiar datos y sincronizarse con otras federaciones.
• Federación : un conjunto de federaciones que se conectan al mismo RTI junto con un FOM común.
• Ejecución de la 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 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 del modelo de objetos HLA y el esquema XML asociado. Se utilizan diferentes FOM para intercambiar datos para diferentes dominios de aplicación. Hay FOM estandarizados, llamados 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 utilizando 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 utilizando una clase de objeto.
• Interacción : la interacción se utiliza 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 objeto). 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 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 sus valores de atributo. 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.
• Suscripción : una federación que se suscribe a una clase de objeto con un conjunto de atributos descubrirá 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 los parámetros asociados.

Especificación de interfaz

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

La mayoría de los 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. El RTI entrega información a una federación mediante devoluciones de llamada, que se entregan mediante llamadas a una instancia de la clase Federate Ambassador. En la API de servicios web, definida mediante WSDL , la federación realiza llamadas y recupera las devoluciones de llamada mediante solicitudes y respuestas de servicios web.

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

Servicios de administración de la federación

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 la 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 utiliza 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 usa 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. Estos son eventos de toda la federación en los que todos o los federados seleccionados deben completar una operación, como inicializar 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 las federaciones que se ha registrado un punto de sincronización
• SynchronizationPoint Alcanzado que es utilizado por una federación para indicar que ha alcanzado un punto de sincronización.
• FederationSynchronized que utiliza el RTI para informar a las federaciones que la federación está sincronizada, es decir, todas las federaciones han alcanzado el punto de sincronización.

Otro conjunto de servicios más se relaciona con guardar y restaurar la ejecución de una federación. Una operación de guardado requiere que tanto el RTI como cada federado realicen un guardado de su estado interno. Una operación de restauración requiere que tanto el RTI como cada federación realicen una restauración de su estado interno. Los servicios clave son:

Ahorrar:

• RequestFederationSave que se utiliza para iniciar un guardado de una federación
• InitiateFederateSave que utiliza el RTI para notificar a los federados que comiencen a guardar su estado
• FederateSaveComplete que será invocado 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 usa 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 será invocado por un federado cuando haya completado la restauración de su estado.
• FederationRestored que es utilizado por el RTI para notificar a los federados que la federación está restaurada

Servicios de gestión de declaraciones

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) basándose en clases de objeto e interacción en la FOM. . El RTI utiliza esta información para enrutar 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, toda la interacción, incluidos todos los parámetros, se publica y se suscribe. 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 usa para publicar una clase de interacción que incluye todos los parámetros
• SubscribeInteractionClass que se usa para suscribirse a una clase de interacción que incluye todos los parámetros

Servicios de gestión de objetos

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 a las federaciones compartir información sobre instancias de objetos e intercambiar interacciones.

Los nombres de instancia de objeto se pueden reservar o generar automáticamente. Las federaciones pueden registrar instancias de objetos de clases de objetos especificadas, que luego se descubren mediante las federaciones suscritas. Los atributos de estas instancias de objetos se pueden actualizar. Estas actualizaciones se reflejarán en los federados que se suscriban. Se pueden enviar interacciones. Estas interacciones se entregarán a los federados que se suscriban. Los servicios clave son:

Objetos:

• ReserveObjectInstanceName que se usa para reservar un nombre que se usará para una instancia de objeto
• RegisterObjectInstance que se utiliza para registrar una instancia de objeto de una clase de objeto en particular, ya sea con un nombre reservado o un nombre generado automáticamente.
• DiscoverObjectInstance que utiliza RTI para notificar a las federaciones que se suscriben a una clase de objeto particular que se ha registrado una nueva instancia de objeto.
• DeleteObjectInstance que se usa para eliminar una instancia de objeto
• RemoveObjectInstances que utiliza RTI para notificar a las federaciones 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 el RTI para notificar a las federaciones que se suscriben a atributos particulares de valores actualizados.

Interacciones:

• SendInteraction que se utiliza para enviar una interacción de una clase de interacción en 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 en particular.

Servicios de administración de propiedad

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 un federado puede actualizar un atributo determinado de una instancia de objeto determinada. Ese federado 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 ser propietarios, 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 un federado que se deshaga del atributo y otro federado que adquiera el atributo. Hay dos patrones principales: "tirar" que son iniciados por la federación adquirente y "empujar" que son iniciados por la federación 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 una federación 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 una federación que desea desinvertir atributos solo si hay alguna otra federación que esté lista para adquirir la propiedad de estos atributos.
• NegotiateAttributeOwnershipDivestiture, que es similar pero también puede hacer que el RTI intente encontrar un nuevo propietario.
• UnconditionalAttributeOwnershipDivestiture, que es utilizado por una federación que desea ceder 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.

Servicios de gestión del tiempo

El intercambio de información en una federación de HLA tiene lugar en tiempo real con la entrega inmediata de mensajes (orden de recepción, RO), a menos que se haya habilitado la gestión de tiempo de HLA. El propósito de HLA Time Management, descrito 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 Time Stamp Order (TSO), sin importar si la federación se ejecuta en tiempo real, más rápido que en tiempo real, más lento que el tiempo real o tan rápido como sea posible.

Algunos conceptos importantes en HLA Time Management son:

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

Lookahead : un intervalo de tiempo que especifica el tiempo más bajo en el futuro para el cual una federación producirá mensajes. Para una federación con un intervalo de tiempo fijo, suele ser la duración del intervalo de tiempo.

Concedido : El RTI concede (permite avanzar) a un federado a un tiempo lógico particular, cuando se han entregado todos los mensajes con marca de tiempo hasta ese momento. Luego, la federación puede comenzar a calcular de manera segura los mensajes con una marca de tiempo en el futuro. Esta marca de tiempo no puede ser anterior al tiempo otorgado más la anticipación de los federados.

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

Regulación de tiempo : Una federación que envía eventos con marca de tiempo se considera Reguladora de tiempo ya que el avance de tiempo por parte de otras federaciones puede estar regulado por esto.

Con restricción de tiempo : una federación que recibe eventos administrados por tiempo se considera con restricción de tiempo ya que la recepción de mensajes con marca de tiempo restringe su avance de tiempo.

Los principios fundamentales de HLA Time Management son los siguientes:

• Cada federación asigna una marca de tiempo a los mensajes (actualizaciones e interacciones) cuando se envían, indicando para qué tiempo de escenario es válido el mensaje.
• Los federados solicitan permiso a la RTI para adelantar su tiempo.
• El RTI gestiona la entrega de mensajes y otorga a los federados un adelanto de tiempo para que los mensajes se entreguen en el orden de marca de tiempo y que los federados no reciban ningún mensaje con una marca de tiempo en su pasado.

Ejemplo de Lookahead, concedido y avanzado:

1. Un federado usa un intervalo de tiempo fijo de 10 y tiene un Lookahead de 10.
2. El RTI concede al federado el tiempo lógico 50. El RTI garantiza así que todos los mensajes con un intervalo de tiempo menor o igual a 50 se han entregado a la federación.
3. La federación ahora tiene todos los datos necesarios para calcular correctamente y enviar mensajes para el tiempo otorgado más Lookahead, es decir, 60.
4. Cuando la federación ha enviado todos los mensajes con la marca de tiempo 60, solicita que se avance a la hora 60. Por lo tanto, se compromete a no enviar ningún mensaje con una marca de tiempo inferior a 70.
5. El RTI entrega todos los mensajes con marca de tiempo menor o igual a 60 a la federación. Luego otorga al federado el tiempo 60.
6. Etc.

Si al menos un federado en la federación realiza el ritmo, 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 ritmo, la federación se ejecutará lo más rápido posible, lo que se utiliza, por ejemplo, en la simulación de Monte Carlo.

Los servicios clave incluyen:

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

Para la simulación impulsada por eventos, también es posible que una federación solicite avanzar al siguiente evento utilizando el siguiente servicio:

• NextMessageRequest mediante el cual una federación solicita avanzar a la marca de tiempo del siguiente mensaje que debe entregarse a la federación, o un tiempo lógico especificado, lo que tenga una marca de tiempo más baja.

Otro concepto importante es el tiempo lógico más grande disponible (GALT). El tiempo máximo que se le puede otorgar a cada federación depende del tiempo que se haya otorgado a otros federados, así como de su anticipación. El GALT para una federación especifica hasta qué punto se puede otorgar una federación, sin tener que esperar a que se otorguen 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:

• QueryGALT que devuelve 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.
• Retracción mediante la cual un federado puede solicitar que se retire un mensaje ya enviado. Esto es útil en la simulación optimista.

Servicios de gestión de distribución de datos (DDM)

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 los 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 marca de automóvil).

Los conceptos clave de DDM son:

Dimensión : un intervalo con nombre (0..n) utilizado para el filtrado, con valores que comienzan con 0 y terminan con un límite superior n. Los datos del 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 basada 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 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 número entero en el rango 0..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 número 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 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 cuando se suscribe a atributos e interacciones de clase de objeto. Las regiones también se utilizan al enviar interacciones y actualizaciones de atributos. Cuando se utiliza DDM, las actualizaciones de atributos y las interacciones 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 usa 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 con 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 usa para suscribirse a interacciones donde las regiones usadas para la suscripción se superponen con las regiones de las interacciones.
• SendInteractionsWithRegions que se usa para enviar interacciones con regiones asociadas.

Servicios de apoyo

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. Éstos incluyen:

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

Modelo de objetos de gestión

El propósito 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 realiza mediante el objeto MOM y las clases de interacción. Los objetos MOM se definen en un módulo FOM especial llamado MIM, que el RTI carga automáticamente. Las características clave de MOM incluyen:

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

Plantilla de modelo de objeto (OMT)

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 SOM se pueden representar en formato tabular o mediante XML. El último formato se utiliza cuando se carga un FOM en el 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.

El estándar proporciona 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 OMT:

• El esquema OMT DIF XML, que verifica que un documento OMT sigue el formato OMT básico, pero no que esté completo y tenga integridad referencial.
• El esquema XML OMT FDD, que verifica que un documento OMT contiene suficiente información para ser útil por un 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 tenga integridad referencial.

Tabla de identificación

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

Muestra de tabla de identificación de HLA

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 la aplicación, Descripción, Limitación de uso e Historial de uso
• Palabras clave: valores de palabras clave y taxonomía utilizada
• Punto de contacto (POC): Tipo (autor principal / Colaborador / Proponente / Patrocinador / Autoridad de publicación / POC técnico), nombre de POC, organización de POC, teléfono de POC, correo electrónico de POC
• Referencias: Tipo (documento de texto / hoja de cálculo / archivo de Powerpoint / FOM independiente / FOM de dependencia / Compuesto de FOM), Identificación (nombre del documento o nombre de FOM)
• Otro
• Glifo (icono)

Tabla de estructura de clases de objetos

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 crear instancias de 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 conoce como HLAobjectRoot. Un ejemplo de un nombre completo de una clase de objeto es HLAobjectRoot.Car.ElectricCar

Ejemplo de tabla de clases de objetos HLA

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

• Nombre
• Publicación (Publicar / Suscribir / Publicar Suscribir / Ninguno)

Tabla de atributos

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 están definidos localmente en la clase de objeto o especificados en cualquier superclase directa o indirecta.

Ejemplo de tabla de atributos HLA

Los siguientes campos se especifican para un atributo

• Nombre de clase de 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 (Divest / Acquire / NoTransfer / DivestAcquire): si el atributo se puede desinvertir o adquirir mediante los servicios de propiedad de HLA
• P / S (Publicar / Suscribir / Publicar Suscribir / Ninguno): si el atributo se puede publicar y / 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 / BestEffort / otros transportes descritos en la tabla Transporte)
• Pedido (recepción / marca de tiempo): orden de entrega para actualizaciones de atributos.

Tabla de estructura de clases de interacción

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 la clase 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 un nombre completo de una clase de interacción es HLAinteractionRoot.CarCommand.Start.

Ejemplo de tabla de clases de interacción HLA

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

• Nombre
• Publicación (Publicar / Suscribir / Publicar Suscribir / Ninguno)

Tabla de parámetros

El propósito de la tabla de parámetros es especificar los parámetros que están disponibles para una determinada clase de interacción. Dado que los parámetros se heredan, una clase de interacción tendrá la unión de todos los parámetros que están definidos localmente en la clase de interacción o especificados en cualquier superclase directa o indirecta.

Ejemplo de tabla de parámetros HLA

Tabla de dimensiones

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

Tabla de representación de tiempo

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.

Tabla de etiquetas proporcionada por el usuario

Se puede proporcionar una etiqueta proporcionada por el usuario al llamar a determinados servicios HLA. El propósito de la tabla de etiquetas proporcionada por el usuario es especificar los tipos de datos de estas etiquetas.

Tabla de sincronizacion

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

Tabla de tipos de transporte

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

Tabla de tasas de actualización

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

Mesa de interruptores

El comportamiento en tiempo de ejecución del RTI se puede controlar mediante varios conmutadores predefinidos. El propósito de la tabla de interruptores es proporcionar valores iniciales para estos interruptores. Algunos de los conmutadores también se pueden actualizar en tiempo de ejecución.

Tipos de datos

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 de tiempo, etiqueta proporcionada por el usuario y puntos de sincronización. Hay seis categorías de tipos de datos, con un formato tabular separado para cada uno de ellos.

Tabla de representación de datos básicos

El propósito de la tabla de representación de datos básica es proporcionar representaciones binarias para su uso en otras tablas. Se proporcionan varios tipos de datos básicos predefinidos en el estándar HLA: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteger64LE, HLAfloat32LEPair, HLAfloatLA El conjunto de tipos de datos básicos generalmente no se amplía con los tipos de datos básicos definidos por el usuario.

Tabla de tipos de datos simples

Ejemplo de tabla de tipos de datos simples HLA

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.

Tabla de tipos de datos enumerados

Ejemplo de tabla de tipos de datos enumerados de HLA

El propósito de la tabla de tipos de datos enumerados es describir elementos de datos que pueden tomar un conjunto de valores finito y discreto. 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 una FOM.

Tabla de tipos de datos de matriz

Tabla de tipos de datos de matriz HLA de muestra

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.

Tabla de tipos de datos de registros fijos

Ejemplo de tabla de tipos de datos de registros fijos HLA

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). Es común incluir tipos de datos simples definidos por el usuario en un FOM. No se proporcionan tipos de datos simples predefinidos en el estándar HLA.

Tabla de tipos de datos de registros de variantes

Tabla de notas

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

Reglas HLA

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

1. Las federaciones deberán tener un modelo de objetos de federación de HLA (FOM), documentado de acuerdo con la plantilla de modelo de objetos de HLA (OMT).
2. En una federación, toda la representación de objetos en la FOM estará en las federaciones, no en la infraestructura de tiempo de ejecución (RTI).
3. Durante la ejecución de una federación, todo intercambio de datos de FOM entre federados se realizará a través del RTI.
4. Durante la ejecución de una federación, los federados interactuarán 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 será propiedad de un solo federado en un momento dado.
6. Los federados deberán tener un modelo de objetos de simulación de HLA (SOM), documentado de acuerdo con la plantilla de modelo de objetos de 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, como se especifica en su SOM.
8. Los federados podrán transferir y / o aceptar la propiedad de un atributo dinámicamente durante la ejecución de una 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, como se especifica en su SOM.
10. Los federados podrán gestionar la hora local de forma que les permita coordinar el intercambio de datos con otros miembros de una federación.

HLA evolucionado

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

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

Conformidad con la Federación

Para asegurar la interacción adecuada entre simulaciones, se define una forma de probar la conformidad federada. Esto implica asegurarse de que todas las clases e interacciones enumeradas en el SOM para un federado en particular se utilicen de acuerdo con el uso descrito, "PublicarSuscribir", "Publicar", "Suscribir" o "Ninguno".

STANAG 4603

HLA (tanto en la versión actual IEEE 1516 como en su 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]

Estándares relacionados

Modelo de objeto base

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 las simulaciones de HLA. Proporciona una forma de especificar modelos conceptuales y cómo asignarlos a una FOM HLA. ^[14]

Alternativas

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 HLA RTI también incluyen DIS en sus productos. En cuanto a las aplicaciones de middleware que más se acercan 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 el cable para la interoperabilidad del sistema. ^[15]

Crítica

HLA es un middleware orientado a mensajes que se define como un conjunto de servicios, proporcionado por una API de C ++ o Java . No existe un protocolo en línea estandarizado. 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.

Ver también

• Lista de ITR comerciales y no comerciales
• Simulación por ordenador
• Computación distribuída
• Organización de estándares de interoperabilidad de simulación

Referencias

1. Kuhl, Frederick; Weatherly, Richard; Dahmann, Judith (18 de octubre de 1999). Creación de sistemas de simulación por computadora: una introducción a la arquitectura de alto nivel (1 ed.). Prentice Hall. ISBN 0130225118.
2. Dahmann, Judith (1997). "Arquitectura de alto nivel del Departamento de Defensa" (PDF) . Actas de la Conferencia de simulación de invierno de 1997 : 142-149. doi : 10.1145 / 268437.268465 . ISBN  078034278X.
3. STANAG 4603: Estándares de arquitectura de modelado y simulación para interoperabilidad técnica: Arquitectura de alto nivel (HLA) . OTAN.
4. Estándar IEEE para modelado y simulación (M&S) Arquitectura de alto nivel (HLA) - Marco y reglas . Sociedad de Informática IEEE. 18 de agosto de 2010. ISBN 978-0-7381-6251-5.
5. Estándar IEEE para modelado y simulación (M&S) Arquitectura de alto nivel (HLA) - Especificación de interfaz federada . Sociedad de Informática IEEE. 18 de agosto de 2010. ISBN 978-0-7381-6247-8.
6. Estándar IEEE para modelado y simulación (M&S) Arquitectura de alto nivel (HLA) - Especificación de plantilla de modelo de objeto (OMT) . Sociedad de Informática IEEE. 18 de agosto de 2010. ISBN 978-0-7381-6249-2.
7. Möller, Björn; Morse, Kathrine L; Lightner, Mike; Pequeño, Reed; Lutz, Bob (abril de 2008). "HLA evolucionado - un resumen de las principales mejoras técnicas" . Actas del Taller de interoperabilidad de simulación de primavera de 2008 .
8. Möller, Björn; Löfstrand, Björn (septiembre de 2009). "Introducción a los módulos FOM" . Actas del Taller de interoperabilidad de simulación de otoño de 2009 .
9. Möller, Björn; Löf, Staffan (septiembre de 2006). "Una descripción general de la administración de la API de servicios web evolucionados de HLA" . Actas del Taller de interoperabilidad de simulación de otoño de 2006 .
10. Möller, Björn; Karlsson, Mikael; Löfstrand, Björn (abril de 2005). "Desarrollo de federaciones tolerantes a fallas utilizando HLA Evolved" . Actas del taller de interoperabilidad de simulación de primavera de 2005 .
11. Möller, Björn; Fredrik, Antelius; Martin, Johansson; Mikael, Karlsson (septiembre de 2016). "Construcción de simulaciones distribuidas escalables: patrones de diseño para HLA DDM" . Actas del Taller de interoperabilidad de simulación de otoño de 2016 . Consultado el 13 de noviembre de 2019 .
12. Oficina de simulación y modelado de defensa de Estados Unidos (2001). RTI 1.3: Guía del programador de próxima generación, versión 4 . Departamento de Defensa de Estados Unidos .
13. "Desarrollo de STANAG de arquitectura de alto nivel (MSG-033)" . Consultado el 3 de marzo de 2015 .
14. Estándar SISO BOM
15. Doshi, Rajiv; Castellote, Gerardo-Pardo (2006). "Una comparación de HLA y DDS" (PDF) . Innovaciones en tiempo real . Consultado el 3 de marzo de 2015 .
16. Granowetter, Len. "Problemas de interoperabilidad de RTI: estándares API, estándares de cables y puentes RTI" . Consultado el 14 de marzo de 2018 .

enlaces externos

• Errata según el estándar IEEE para modelado y simulación (M&S) Arquitectura de alto nivel (HLA) - Especificación de interfaz federada
• Interpretaciones del Departamento de Defensa (DoD) de la serie de estándares IEEE 1516-2000, versión 2 (2003-jul-01)