El Protocolo de Simulación de Nivel Agregado (ALSP) es un protocolo y un software de soporte que permite la interoperabilidad entre simulaciones. Sustituido por la Arquitectura de Alto Nivel (simulación) (HLA) , fue utilizado por el ejército estadounidense para vincular simulaciones analíticas y de entrenamiento.
ALSP consta de:
- Software de infraestructura ALSP (AIS) que proporciona soporte y gestión de simulación en tiempo de ejecución distribuidos;
- Una interfaz ALSP reutilizable que consta de protocolos genéricos de intercambio de mensajes de datos; y
- Simulaciones participantes adaptadas para su uso con ALSP.
Historia
En 1990, la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) contrató a The MITRE Corporation para estudiar la aplicación de los principios de simulación interactiva distribuida empleados en SIMNET a simulaciones de entrenamiento constructivo a nivel agregado. A partir de los esfuerzos del prototipo, en 1991 se llevó a cabo un experimento comunitario para extender SIMNET y conectar la Simulación de Batalla de Cuerpos (CBS) del Ejército de los EE. UU. con la Simulación de Guerra Aérea (AWSIM) de la Fuerza Aérea de los EE. UU. El éxito del prototipo y el reconocimiento por parte de los usuarios del valor de esta tecnología para la comunidad de entrenamiento condujeron al desarrollo del software de producción. La primera confederación ALSP, que proporcionó interacciones aire-tierra entre CBS y AWSIM, apoyó tres ejercicios importantes en 1992.
Para 1995, ALSP se había transformado en un programa multiservicio con simulaciones que representaban al Ejército de los EE. UU. (CBS), la Fuerza Aérea de los EE. UU. (AWSIM), la Armada de los EE. UU. ( RESA ), el Cuerpo de Marines de los EE. UU. ( MTWS ), la guerra electrónica ( JECEWSI ), la logística ( CSSTSS ) y la inteligencia ( TACSIM ). El programa también había pasado del enfoque en investigación y desarrollo de DARPA a la gestión principal a cargo de la Oficina Ejecutiva de Programas para Simulación, Entrenamiento e Instrumentación ( PEO STRI ) del Ejército de los EE. UU.
Contribuciones
ALSP desarrolló y demostró aspectos clave de la simulación distribuida, muchos de los cuales se aplicaron en el desarrollo de HLA.
- No hay un nodo central, por lo que las simulaciones pueden unirse y abandonar la confederación a voluntad.
- Distribución geográfica donde los simuladores pueden distribuirse en diferentes ubicaciones geográficas pero ejercitarse en el mismo entorno simulado.
- Propiedad de los objetos, de modo que cada simulación controla sus propios recursos, dispara sus propias armas y determina el daño apropiado a sus sistemas cuando recibe disparos.
- Un protocolo basado en mensajes para distribuir información de una simulación a todas las demás simulaciones.
- Gestionar el tiempo de forma que los tiempos de todas las simulaciones parezcan iguales para los usuarios y que se mantenga la causalidad de los eventos: los eventos deben ocurrir en la misma secuencia en todas las simulaciones.
- La gestión de datos permite que todas las simulaciones compartan información de forma común, aunque cada una tenga su propia representación de los datos. Esto incluye que varias simulaciones controlen atributos del mismo objeto.
- Una arquitectura que permite que las simulaciones sigan utilizando sus arquitecturas existentes mientras participan en una confederación ALSP.
Motivación
En 1989, el Centro de Preparación de Guerreros (WPC) en Einsiedlerhof, Alemania, fue sede del ejercicio militar computarizado ACE-89. La Agencia de Proyectos de Investigación Avanzada de Defensa ( DARPA ) aprovechó ACE-89 como una oportunidad para la inserción de tecnología, financiando el despliegue de la Internet de Simulación de Defensa (DSI). Su sistema de videoconferencia por paquetes permitió que, por primera vez, oficiales generales de países de la OTAN se reunieran cara a cara durante un ejercicio militar; esto fue bien recibido. Sin embargo, la aplicación de software de DSI, la Simulación de Guerra Terrestre (GRWSIM), tuvo menos éxito. La simulación GRWSIM era poco fiable y su base de datos distribuida era inconsistente, lo que redujo la efectividad del ejercicio.
DARPA financió el desarrollo de un sistema de entrenamiento de tanques distribuido llamado SIMNET, donde simuladores individuales y computarizados para tripulaciones de tanques se conectaban a través de redes de área local y el DSI para cooperar en un único campo de batalla virtual. El éxito de SIMNET, la decepción de ACE-89 y el deseo de combinar las simulaciones de combate existentes impulsaron a DARPA a iniciar una investigación que dio lugar al ALSP.
Principios básicos
DARPA patrocinó el diseño de una interfaz general entre simulaciones de combate a gran escala, existentes y de nivel agregado. Estas simulaciones utilizan modelos de combate tipo Lanchestrian en lugar de modelos individuales de armas físicas y se emplean habitualmente para entrenamiento de alto nivel. A pesar de las diferencias de representación, varios principios de SIMNET se aplicaron a las simulaciones de nivel agregado:
- Configurabilidad dinámica. Las simulaciones pueden unirse y abandonar un ejercicio sin restricciones.
- Distribución geográfica. Las simulaciones pueden residir en diferentes ubicaciones geográficas, pero desarrollarse sobre el mismo terreno lógico.
- Entidades autónomas. Cada simulación controla sus propios recursos, dispara sus propias armas y, cuando uno de sus objetos es alcanzado, realiza una evaluación de daños localmente.
- Comunicación mediante paso de mensajes. Una simulación utiliza un protocolo de paso de mensajes para distribuir información a todas las demás simulaciones.
El desafío ALSP tenía requisitos que iban más allá de los de SIMNET:
- Gestión del tiempo de simulación. Normalmente, el tiempo de simulación es independiente del tiempo real. Para que los resultados de una simulación distribuida sean "correctos", el tiempo debe ser consistente en todas las simulaciones. [ 1 ]
- Gestión de datos. Los esquemas de representación del estado interno difieren entre las simulaciones existentes, lo que requiere un sistema de representación común y los consiguientes mecanismos de mapeo y control.
- Independencia de la arquitectura. Las características arquitectónicas (lenguaje de implementación, interfaz de usuario y mecanismo de flujo temporal) de las simulaciones existentes diferían. La arquitectura implícita en ALSP debe ser compatible con las arquitecturas existentes.
Marco conceptual
Un marco conceptual es una estructura organizativa de conceptos que facilita el desarrollo de modelos de simulación. [ 2 ] Los marcos conceptuales comunes incluyen: programación de eventos, escaneo de actividades e interacción de procesos.
El marco conceptual de ALSP se basa en objetos, donde un modelo se compone de objetos caracterizados por atributos a los que se asignan valores. Las clases de objetos se organizan jerárquicamente de forma similar a como se hace en los lenguajes de programación orientados a objetos . ALSP admite una confederación de simulaciones que se coordinan mediante un modelo común.
Para diseñar un mecanismo que permita la interacción entre simulaciones existentes, son posibles dos estrategias: (1) definir una infraestructura que traduzca entre las representaciones de cada simulación, o (2) definir un esquema de representación común y exigir que todas las simulaciones se ajusten a ese esquema.
La primera estrategia requiere pocas modificaciones a las simulaciones existentes; la interacción se facilita completamente a través de la infraestructura de interconexión. Sin embargo, esta solución no es escalable. Debido a la necesidad subyacente de escalabilidad, el diseño de ALSP adoptó la segunda estrategia. ALSP prescribe que cada simulación se mapee entre el esquema de representación de la confederación y su propio esquema de representación. Este mapeo representa una de las tres formas en que una simulación debe modificarse para participar en una confederación ALSP. Las modificaciones restantes son:
- Reconocer que la simulación no posee todos los objetos que percibe.
- Modificar el mecanismo interno de avance temporal de la simulación para que funcione de forma cooperativa con las demás simulaciones dentro de la confederación.
En las simulaciones independientes, los objetos aparecen (y desaparecen) con el transcurso del tiempo de simulación, y su destino es responsabilidad exclusiva de la simulación. Al operar dentro de una confederación, la relación entre la simulación y los objetos es más compleja.
La propiedad de propiedad de los objetos de simulación es dinámica; es decir, durante su ciclo de vida, un objeto puede pertenecer a más de una simulación. De hecho, para cualquier valor de tiempo de simulación, varias simulaciones pueden poseer diferentes atributos de un objeto dado. Por convención, una simulación posee un objeto si posee el atributo que lo identifica. Poseer un atributo de un objeto implica que la simulación es responsable de calcular e informar sobre los cambios en el valor de dicho atributo. Los objetos que no pertenecen a una simulación en particular, pero que se encuentran dentro de su área de percepción, se conocen como fantasmas. Los fantasmas son copias locales de objetos que pertenecen a otras simulaciones.
Cuando una simulación crea un objeto, informa de ello a la confederación para que otras simulaciones puedan crear fantasmas. Del mismo modo, cuando una simulación elimina un objeto, informa de ello para permitir la eliminación de fantasmas. Siempre que una simulación realiza una acción entre uno de sus objetos y un fantasma, debe informar de ello a la confederación. En la terminología de ALSP, esto se denomina interacción. Estos conceptos fundamentales constituyen la base del resto de la presentación. El término modelo de confederación describe la jerarquía de objetos, los atributos y las interacciones que admite una confederación.
Software de infraestructura ALSP (AIS)
El marco conceptual basado en objetos adoptado por ALSP define las clases de información que deben distribuirse. El software de infraestructura de ALSP (AIS) proporciona distribución de datos y coordinación de procesos. Los componentes principales de AIS son el módulo común de ALSP (ACM) y el emulador de difusión de ALSP (ABE).
Módulo común de ALSP (ACM)
El Módulo Común de ALSP (ACM) proporciona una interfaz común para todas las simulaciones y contiene la funcionalidad esencial para ALSP. Existe una instancia de ACM para cada simulación en una confederación. Los servicios de ACM requieren gestión de tiempo y gestión de objetos; estos incluyen:
- Coordinar simulaciones de entrada y salida de una confederación.
- Coordinar la hora local de la simulación con la hora de la confederación.
- Filtra los mensajes entrantes para que las simulaciones reciban solo los mensajes de interés.
- Coordinar la propiedad de los atributos de los objetos y permitir la migración de la propiedad.
- Garantizar la propiedad de los atributos para que las simulaciones informen valores solo para los atributos que les pertenecen.
Gestión del tiempo
Unirse o abandonar una confederación es parte integral del proceso de gestión del tiempo. Cuando una simulación se une a una confederación, todos los demás ACM de la confederación crean colas de mensajes de entrada para la nueva simulación. Por el contrario, cuando una simulación abandona una confederación, los demás ACM eliminan las colas de mensajes de entrada para esa simulación.
Las funciones de gestión de tiempo de ALSP admiten la simulación de eventos discretos utilizando mecanismos de avance de tiempo asíncronos (evento siguiente) o síncronos (paso de tiempo). [ 3 ] El mecanismo para admitir simulaciones de evento siguiente es
- Una simulación envía un mensaje de solicitud de evento a su ACM con un parámetro de tiempo que corresponde al tiempo de simulación T (el tiempo de su próximo evento local).
- Si el ACM tiene mensajes para su simulación con marcas de tiempo anteriores o iguales a T, el ACM envía el más antiguo a la simulación. Si todos los mensajes tienen marcas de tiempo posteriores a T, el ACM envía un anticipo de autorización a la simulación, otorgándole permiso para procesar su evento local en el instante T.
- La simulación envía a su ACM cualquier mensaje resultante del evento.
- La simulación se repite desde el paso (1).
El mecanismo para admitir la simulación por pasos de tiempo es:
- La simulación procesa todos los eventos durante un intervalo de tiempo determinado..
- La simulación envía una solicitud anticipada a su ACM para obtener tiempo..
- El ACM envía todos los mensajes con marcas de tiempo en el intervaloa la simulación, seguida de un anticipo de subvención a T+?T.
- La simulación envía cualquier mensaje para el intervaloa la ACM.
- La simulación se repite desde el paso (1).
AIS incluye un mecanismo para evitar interbloqueos mediante mensajes nulos. Este mecanismo requiere que los procesos tengan características de anticipación que puedan ser explotadas .
Gestión de objetos
El ACM administra la base de datos de atributos y la información de filtrado. La base de datos de atributos mantiene los objetos conocidos por la simulación, ya sean propios o fantasma, y los atributos de aquellos objetos que la simulación posee actualmente. Para cualquier clase de objeto, los atributos pueden ser miembros de
- Crear conjunto. Atributos mínimos necesarios para representar un objeto.
- Conjunto de intereses. Información útil, pero no obligatoria.
- Conjunto de actualización. Valores de atributos de objeto informados por una simulación a la confederación.
El flujo de información a través de la red puede restringirse aún más mediante filtros. El filtrado permite discriminar según (1) la clase de objeto, (2) el valor o rango del atributo y (3) la ubicación geográfica. Los filtros también definen las interacciones relevantes para una simulación.
Si (una actualización cumple con todos los criterios de filtro) Si (el objeto es conocido por la simulación) | | Enviar nuevos valores de atributos a la simulación | De lo contrario (el objeto es desconocido) | | Si (hay suficiente información para crear un fantasma) | | | Enviar un mensaje de creación a la simulación | | En caso contrario (no se dispone de suficiente información) | | | Información de la tienda proporcionada | | | Enviar una solicitud a la confederación para obtener los datos faltantes De lo contrario (la actualización no cumple con los criterios de filtrado) Si (el objeto es conocido por la simulación) | | Enviar un mensaje de eliminación a la simulación | De lo contrario | | Descartar los datos de actualización
La información sobre la propiedad y el filtrado que mantiene la ACM proporciona la información necesaria para coordinar la transferencia de la propiedad de los atributos entre simulaciones.
Emulador de difusión ALSP (ABE)
Un emulador de difusión ALSP (ABE) facilita la distribución de información ALSP. Recibe un mensaje en una de sus rutas de comunicación y lo retransmite por todas las demás. Esto permite configuraciones donde todos los componentes ALSP se encuentran en la misma red local (en el mismo ordenador o en una red de área local ). También permite configuraciones donde conjuntos de ACM se comunican con su propio ABE local, con comunicación entre ABE a través de redes de área amplia.
Esquema de comunicación
El esquema de comunicación ALSP consta de (1) un modelo de comunicaciones entre componentes que define la interfaz de la capa de transporte que conecta los componentes ALSP, (2) un protocolo en capas para la comunicación entre simulaciones, la gestión de objetos y la gestión del tiempo, (3) un esquema de filtrado de mensajes para definir la información de interés para una simulación y (4) un mecanismo para la distribución inteligente de mensajes.
Modelo de comunicaciones entre componentes
AIS emplea un modelo de comunicaciones de conexión persistente [ 4 ] para proporcionar las comunicaciones entre componentes. La interfaz de la capa de transporte utilizada para proporcionar las comunicaciones entre componentes fue dictada por los requisitos de simulación y las interfaces de la capa de transporte en los sistemas operativos que admiten AIS: las plataformas VMS locales usaban buzones compartidos; las plataformas VMS no locales usaban DECnet transparente o TCP/IP; y las plataformas tipo UNIX usaban TCP/IP.
Protocolo ALSP
El protocolo ALSP se basa en un conjunto de cuestiones ortogonales que conforman su ámbito de aplicación: comunicación entre simulaciones, gestión de objetos y gestión del tiempo. Estas cuestiones se abordan mediante un protocolo por capas que, en la capa superior, cuenta con un protocolo de simulación, sobre el cual subyacen protocolos de simulación/ACM, gestión de objetos, gestión del tiempo y distribución de eventos.
Protocolo de simulación
El protocolo de simulación es el nivel principal del protocolo ALSP. Consta de cuatro tipos de mensajes:
- Actualización. En ALSP, los objetos se definen mediante un número de identificación único, una clase y un conjunto de atributos asociados a dicha clase. Cuando una simulación modifica el estado de sus objetos, envía mensajes de actualización al ACM que proporcionan los valores iniciales o modificados de los atributos. El ACM distribuye la información a través del AIS a otras simulaciones que hayan manifestado interés.
- Interacción. Las interacciones entre objetos se identifican por su tipo. Los tipos de interacción se describen mediante parámetros, al igual que los objetos se describen mediante atributos. Cuando un objeto de una simulación interactúa con un objeto de otra simulación o con un área geográfica, la simulación envía un mensaje de interacción a la ACM para su posterior difusión a otras simulaciones interesadas.
- Solicitud de actualización. Una simulación puede solicitar la actualización de un conjunto de valores de atributos para cualquier objeto o clase de objetos enviando un mensaje de solicitud de actualización a la confederación.
- Eliminar. Cuando una simulación provoca que uno de sus objetos deje de existir, envía un mensaje de eliminación para informar a las demás simulaciones.
El protocolo de simulación se basa en texto. Se define mediante una gramática libre de contexto LALR (1). La semántica del protocolo depende de la confederación, donde el conjunto de clases, atributos de clase, interacciones y parámetros de interacción son variables. Por lo tanto, la representación sintáctica del protocolo de simulación puede definirse sin conocimiento previo de la semántica de los objetos e interacciones de ninguna confederación en particular.
Protocolo de conexión de simulación/ACM
El protocolo de conexión simulación/ACM proporciona servicios para gestionar la conexión entre una simulación y su ACM, así como un método de intercambio de información entre ambas. Dos servicios controlan la distribución de los mensajes del protocolo de simulación: eventos y despachos. Los mensajes de evento se marcan con la hora y se entregan en un orden temporalmente coherente. Los mensajes de despacho se entregan lo antes posible, independientemente del tiempo de simulación. Otros mensajes del protocolo proporcionan información sobre el estado de la conexión, el registro de filtros, el control de bloqueo de atributos, el control de guardado de la confederación, el control de recursos de objetos y el control del tiempo.
Protocolo de gestión de objetos
El protocolo de gestión de objetos es un protocolo de nivel de pares que se sitúa por debajo del protocolo de simulación y proporciona servicios de gestión de objetos. Los ACM lo utilizan exclusivamente para la creación, adquisición, liberación y verificación de atributos de objetos (de la coherencia de la base de datos de objetos distribuidos). Estos servicios permiten a los AIS gestionar la propiedad de los objetos distribuidos.
La propiedad distribuida de objetos presupone que ninguna simulación individual debe poseer todos los objetos de una confederación, pero muchas simulaciones requieren conocimiento de algunos objetos. Una simulación utiliza mensajes de actualización del protocolo de simulación para descubrir los objetos que pertenecen a otras simulaciones. Si esta simulación está interesada en los objetos, puede rastrearlos (su ubicación y estado) y modelar las interacciones con ellos desde los objetos que posee.
Los bloqueos implementan la propiedad de los atributos. Una función principal del protocolo de gestión de objetos es asegurar que una simulación solo actualice los atributos para los que ha adquirido un bloqueo. El gestor de objetos en el ACM gestiona los objetos y los atributos de los objetos propios y fantasma conocidos por el ACM. Las simulaciones utilizan los servicios proporcionados por el protocolo simulación/ACM para interactuar con el mecanismo de bloqueo de atributos del ACM. La coordinación del estado, la solicitud, la adquisición y la liberación de los atributos de los objetos entre los ACM utiliza el protocolo de gestión de objetos. Cada atributo de cada objeto conocido por un ACM determinado tiene un estado que asume uno de tres valores:
- Bloqueado. Una simulación controla el atributo y puede actualizar su valor. Una simulación "posee" el atributo si lo tiene bloqueado. Una simulación "posee" el objeto si tiene bloqueado su atributo id.
- Desbloqueado. Ninguna simulación controla actualmente el atributo. Cualquier simulación que solicite el control lo obtendrá.
- Desaparecido. El control estatal se ejerce en otro lugar de la confederación.
Desde la perspectiva de la ACM, los objetos surgen a través del proceso de registro realizado por su simulación o a través del descubrimiento de objetos registrados por otras simulaciones. Los bloqueos de atributos de estado inicial para los objetos registrados y los objetos descubiertos son los siguientes:
- El registro de objetos coloca cada par objeto-atributo en estado bloqueado. Opcionalmente, la simulación puede especificar qué atributos deben estar en estado desbloqueado.
- La función de detección de objetos agrega un objeto a la base de datos de objetos como un objeto fantasma. Todos los atributos de este objeto se marcan con el estado de desaparecido.
Protocolo de gestión del tiempo
El protocolo de gestión del tiempo es un protocolo de nivel de pares que se sitúa por debajo del protocolo de simulación. Proporciona servicios de gestión del tiempo para sincronizar el tiempo de simulación entre los ACM. El protocolo ofrece servicios para la coordinación distribuida de la entrada de una simulación en la confederación, el avance del tiempo y el guardado de la confederación.
Los servicios de unión/renuncia y los mecanismos de sincronización horaria se describen en la sección anterior. El mecanismo de guardado proporciona tolerancia a fallos. Se requiere coordinación para generar una instantánea consistente de todos los ACM, traductores y simulaciones para un valor específico de tiempo de simulación.
Filtrado de mensajes
La ACM utiliza el filtrado de mensajes de simulación para evaluar el contenido de los mensajes recibidos de la confederación. La ACM envía a su simulación los mensajes de interés que cumplen con los criterios de filtrado y descarta los que no son relevantes. La ACM filtra dos tipos de mensajes: mensajes de actualización y mensajes de interacción.
Mensajes de actualización. El ACM evalúa los mensajes de actualización según los criterios de filtrado que proporciona la simulación. Como se mencionó anteriormente, cuando un ACM recibe un mensaje de actualización, existen cuatro resultados posibles: (1) el ACM descarta el mensaje, (2) el ACM envía a la simulación un mensaje de creación, (3) el ACM envía a la simulación un mensaje de actualización o (4) el ACM envía a la simulación un mensaje de eliminación.
Mensajes de interacción. Un ACM puede descartar mensajes de interacción debido al parámetro de tipo. Este parámetro tiene una estructura jerárquica similar a la de la clase de objeto. La simulación informa a su ACM sobre los tipos de interacción que deben pasar o no el filtro de interacción.
Distribución de mensajes
Para minimizar el tráfico de mensajes entre componentes en una confederación ALSP, AIS emplea una forma de enrutamiento inteligente de mensajes que utiliza el Protocolo de Distribución de Eventos (EDP). [ 5 ] El EDP permite a los ACM informar a los demás componentes de AIS sobre los filtros de actualización e interacción registrados por sus simulaciones. En el caso de los mensajes de actualización, la distribución de esta información permite a los ACM distribuir únicamente datos sobre clases (y atributos de clases) que sean de interés para la confederación. El ABE también utiliza esta información para enviar únicamente información que sea de interés para los componentes a los que presta servicio. Para los mensajes de interacción, el proceso es similar, excepto que el parámetro de tipo en el mensaje de interacción determina a dónde se envía el mensaje.
Lecturas adicionales
- Anita Adams, Gordon Miller y David Seidel, noviembre de 1993, "Protocolo de simulación a nivel agregado (ALSP) Informe anual de la Confederación de 1993". Archivado el 9 de octubre de 2007 en Wayback Machine , The MITRE Corporation. Historia del programa ALSP en el año fiscal 1993.
- William E. Babineau, Philip S. Barry, C. Zachary Furness, "Pruebas automatizadas dentro de la Confederación de Entrenamiento Conjunto (JTC)" Archivado el 13 de octubre de 2007 en Wayback Machine , Actas del Taller de Interoperabilidad de Simulación de Otoño de 1998 , Orlando, FL, septiembre de 1998.
- MAJ John Bullington y Gordon Miller, septiembre de 1996, "Apoyo de simulación de inteligencia a la Confederación de Entrenamiento Conjunto: implicaciones para el desarrollo futuro" Archivado el 7 de octubre de 2007 en Wayback Machine , Oficina del Proyecto TACSIM y The MITRE Corporation, publicado en la edición de septiembre de 1996 de Phalanx, una publicación de MORS .
- Lydia P. Dubon, 1993, "Unión a un entorno de simulación distribuido a través de ALSP ", Actas de la Conferencia de Simulación de Invierno de 1993 .
- Laura Feinerman, Gordon Miller, David Prochnow, Richard Weatherly, Annette Wilson y Anita Adams Zabek, "Informe anual de 1994 del proyecto Protocolo de simulación de nivel agregado (ALSP)" . Archivado el 9 de octubre de 2007 en Wayback Machine , con fecha de marzo de 1995, The MITRE Corporation. Historia del programa ALSP en el año fiscal 1994.
- Mary C. Fischer, abril de 1994, "Protocolo de simulación a nivel agregado (ALSP): gestión del desarrollo de la confederación" , Comando de simulación, entrenamiento e instrumentación del Ejército de los EE. UU. Documento presentado en la Conferencia de Internet Elecsim de 1994 .
- Mary C. Fischer, Anita Adams, Gordon Miller, junio de 1994, "Protocolo de simulación a nivel agregado (ALSP): entrenamiento para el futuro". Archivado el 7 de octubre de 2007 en Wayback Machine , Comando de Simulación, Entrenamiento e Instrumentación del Ejército de los EE. UU. y The MITRE Corporation. Documento presentado en el Simposio de Investigación Operativa Militar 62, celebrado en la Academia de la Fuerza Aérea en Colorado Springs, Colorado.
- Mary C. Fischer, diciembre de 1994, «Protocolo de simulación a nivel agregado (ALSP): gestión del desarrollo de la confederación» , Comando de simulación, entrenamiento e instrumentación del Ejército de los Estados Unidos. Documento presentado en la Conferencia de Simulación de Invierno de 1994 en Orlando, Florida.
- Mary C. Fischer, abril de 1995, «Protocolo de simulación a nivel agregado (ALSP): entrenamiento futuro con simulaciones interactivas distribuidas». Archivado el 13 de octubre de 2007 en Wayback Machine , Comando de Simulación, Entrenamiento e Instrumentación del Ejército de los EE. UU. Ponencia presentada en la Conferencia Internacional de Equipos de Entrenamiento de 1995, celebrada del 25 al 27 de abril de 1995 en La Haya, Países Bajos.
- Mary C. Fischer, septiembre de 1995, "Campo de batalla simulado conjunto", archivado el 3 de mayo de 2003 en Wayback Machine , Comando de Simulación, Entrenamiento e Instrumentación del Ejército de los EE. UU., publicado en las Actas del 36.º Seminario del Grupo de Investigación de Defensa (DRG) sobre Modelado y Simulación , del 5 al 8 de septiembre de 1995, Washington, D.C.
- Mary C. Fischer, octubre de 1995, "Plataforma conjunta de simulación de campo de batalla mediante protocolo de simulación a nivel agregado", archivado el 7 de octubre de 2007 en Wayback Machine , Comando de Simulación, Entrenamiento e Instrumentación del Ejército de los EE. UU., publicado en Actas de la Conferencia de Simulación del Sureste '95 , Orlando, FL.
- Mary C. Fischer, marzo de 1996, "Confederación de Entrenamiento Conjunto" Archivado el 13 de octubre de 2007 en Wayback Machine , Comando de Simulación, Entrenamiento e Instrumentación del Ejército de los EE. UU., publicado en Actas de la Primera Conferencia Internacional sobre Tecnología y Entrenamiento de Simulación (SimTecT) , 25-26 de marzo de 1996, Melbourne, Australia.
- Sean P. Griffin, Ernest H. Page, Zachary Furness, Mary C. Fischer, "Proveer entrenamiento ininterrumpido a la Confederación Conjunta de Entrenamiento (JTC) durante la transición a la Arquitectura de Alto Nivel (HLA)" Archivado el 13 de octubre de 2007 en Wayback Machine , Actas de la Conferencia de Tecnología y Entrenamiento de Simulación (SimTecT) de 1997 , Canberra, Australia, 17-20 de marzo de 1997.
- George J. McFadden, "Un enfoque para la gestión de datos enumerados en federaciones", archivado el 7 de octubre de 2007 en Wayback Machine , Actas del Taller de Interoperabilidad de Simulación de Primavera de 2000 , Orlando, FL, marzo de 2000.
- Gordon Miller y Anita Zabek, marzo de 1996, "La Confederación de Entrenamiento Conjunto y el Protocolo de Simulación de Nivel Agregado" Archivado el 7 de octubre de 2007 en Wayback Machine , The MITRE Corporation, publicado en la edición de junio de 1996 de Phalanx, una publicación de MORS .
- Ernest Page; Brad Canova; John Tufarolo (julio de 1997). "Un estudio de caso de verificación, validación y acreditación para simulación distribuida avanzada". ACM Transactions on Modeling and Computer Simulation . CiteSeerX 10.1.1.37.1829 .
- David L. Prochnow; Ernest H. Page; Mary C. Fischer (3–7 de marzo de 1997). "Gestión de la familia de especificaciones de la Confederación Conjunta de Entrenamiento". Actas del Taller de Interoperabilidad de Simulación de Primavera de 1997. Orlando, FL. CiteSeerX 10.1.1.37.935 .
- David L. Prochnow, Mary C. Fischer, "Requisitos únicos para la representación de la logística en un entorno de simulación distribuido para el entrenamiento militar" , Actas del Taller de Interoperabilidad de Simulación de Primavera de 1997 , Orlando, FL, 3-7 de marzo de 1997.
- David L. Prochnow; Ernest H. Page; Bryan Youmans (9–13 de marzo de 1998). "Desarrollo de una herramienta de gestión de federaciones: implicaciones para HLA". Actas del Taller de Interoperabilidad de Simulación de Primavera de 1998. Orlando, FL. CiteSeerX 10.1.1.37.6101 .
- David Seidel, marzo de 1993, "Estado e historial del programa Protocolo de Simulación a Nivel Agregado (ALSP)". Archivado el 9 de octubre de 2007 en Wayback Machine , The MITRE Corporation. Historia del programa ALSP desde sus inicios en 1989 hasta 1992.
- John Tufarolo y Ernest Page, "Evolución del proceso VV&A para la ALSP Joint Training Confederation" , Actas de la Conferencia de Simulación de Invierno de 1996 , págs. 952-958, Coronado, CA, 8-11 de diciembre de 1996.
- Richard Weatherly, David Seidel y Jon Weissman, julio de 1991, "Protocolo de simulación a nivel agregado". Archivado el 13 de octubre de 2007 en Wayback Machine , The MITRE Corporation. Artículo presentado en la Conferencia de Simulación por Computadora de Verano de 1991 en Baltimore, Maryland.
- Richard Weatherly, Annette Wilson y Sean Griffin, diciembre de 1993, "ALSP: Teoría, experiencia y direcciones futuras" , The MITRE Corporation. Ponencia presentada en la Conferencia de Simulación por Computadora de Invierno de 1993 en Los Ángeles, California.
- Weatherly, Richard M.; Wilson, Annette L.; Canova, Bradford S.; Page, Ernest H.; Zabek, Anita A.; Fischer, Mary C. (1996). "Simulación distribuida avanzada mediante el Protocolo de Simulación a Nivel Agregado" . Actas de HICSS-29: 29.ª Conferencia Internacional de Hawái sobre Ciencias de Sistemas . Conferencia Internacional de Hawái sobre Ciencias de Sistemas . pp. 407. CiteSeerX 10.1.1.37.4784 . doi : 10.1109/HICSS.1996.495488 . ISBN 0-8186-7324-9. S2CID 16082035 .
- Annette Wilson y Richard Weatherly, abril de 1994, "Nuevas herramientas de reducción y gestión de tráfico para confederaciones ALSP" , The MITRE Corporation. Documento presentado en la Conferencia de Internet Elecsim de 1994 .
- Annette Wilson y Richard Weatherly, diciembre de 1994, "El protocolo de simulación a nivel agregado: un sistema en evolución" , The MITRE Corporation. Ponencia presentada en la Conferencia de Simulación de Invierno de 1994 en Orlando, Florida.
Referencias
- ↑ Lamport, L. (1978). "Tiempo, relojes y ordenamiento de eventos en un sistema distribuido," Communications of the ACM, 21(7), pp. 558-565, julio.
- ↑ Balci, O., Nance, RE, Derrick, EJ, Page, EH y Bishop, JL (1990). "Problemas de generación de modelos en un entorno de soporte de simulación", En: Actas de la Conferencia de Simulación de Invierno de 1990, págs. 257-263, Nueva Orleans, LA, 9-12 de diciembre.
- ↑ Nance, RE (1971). "Sobre los mecanismos de flujo temporal para simulaciones de eventos discretos," Management Science, 18(l), pp. 59-93, septiembre.
- ↑ Boggs, DR Shoch, JF, Taft, EA y Metcalfe, RM (1979). "PUP: Una arquitectura de interconexión de redes", Informe CSL-79-10, Centro de Investigación XEROX Palo Alto, julio.
- ↑ Weatherly, RM, Wilson, AL y Griffin, SP (1993). "ALSP - Teoría, experiencia y direcciones futuras," En: Actas de la Conferencia de Simulación de Invierno de 1993, págs. 1068-1072, Los Ángeles, CA, 12-15 de diciembre.
- Aplicaciones de la computación distribuida
- Arquitectura de computación distribuida
- protocolos de la capa de aplicación
- Software de simulación
- Corporación Mitre