El Protocolo de simulación de nivel agregado (ALSP) es un protocolo y un software de apoyo que permite que las simulaciones interoperen entre sí. Reemplazado por la Arquitectura de Alto Nivel (simulación) (HLA) , fue utilizado por el ejército de los EE. UU. Para vincular simulaciones analíticas y de entrenamiento.
ALSP consta de:
- Software de infraestructura ALSP (AIS) que brinda soporte y administración de simulación en tiempo de ejecución distribuido;
- Una interfaz ALSP reutilizable que consta de protocolos de mensajes de intercambio de datos genéricos; y
- Simulaciones participantes adaptadas para su uso con ALSP.
Historia
En 1990, la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) empleó a The MITRE Corporation para estudiar la aplicación de los principios de simulación interactiva distribuida empleados en SIMNET para simulaciones de entrenamiento constructivo de nivel agregado. Sobre la base de los esfuerzos de los prototipos, en 1991 se llevó a cabo un experimento comunitario para ampliar SIMNET y vincular la simulación de batalla del cuerpo del ejército de EE. UU. (CBS) y la simulación de guerra aérea de la Fuerza Aérea de EE . El éxito del prototipo y el reconocimiento de los usuarios del valor de esta tecnología para la comunidad de formación llevó al desarrollo de software de producción. La primera confederación ALSP, que proporcionó interacciones aire-tierra entre CBS y AWSIM, apoyó tres ejercicios principales en 1992.
Para 1995, ALSP había hecho la transición a un programa de servicios múltiples con simulaciones que representaban al Ejército de los EE. UU. (CBS), la Fuerza Aérea de los EE. UU. (AWSIM), la Marina de los EE. UU. ( RESA ), el Cuerpo de Marines de los EE. UU. ( MTWS ), la guerra electrónica ( JECEWSI ) , logística ( CSSTSS ) e inteligencia ( TACSIM ). El programa también había pasado del énfasis en investigación y desarrollo de DARPA a la gestión general de la Oficina Ejecutiva del Programa de Simulación, Entrenamiento e Instrumentación del Ejército de los EE. UU. ( PEO STRI ).
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 nodo central para que las simulaciones puedan unirse y salir de la confederación a voluntad.
- Distribución geográfica donde los simuladores se pueden distribuir a diferentes ubicaciones geográficas pero ejercitarse en el mismo entorno simulado
- Propiedad del objeto para que cada simulación controle sus propios recursos, dispare sus propias armas y determine el daño apropiado a sus sistemas cuando se dispara
- Un protocolo basado en mensajes para distribuir información de una simulación a todas las demás simulaciones.
- Gestión del tiempo para que los tiempos de todas las simulaciones parezcan iguales para los usuarios y para 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 una manera comúnmente entendida, aunque cada una tenga su propia representación de datos. Esto incluye múltiples simulaciones que controlan los atributos del mismo objeto.
- Una arquitectura que permite que las simulaciones continúen usando sus arquitecturas existentes mientras participan en una confederación ALSP.
Motivación
En 1989, el Warrior Preparation Center (WPC) en Einsiedlerhof, Alemania, acogió el ejercicio militar computarizado ACE-89. La Agencia de Proyectos de Investigación Avanzada de Defensa ( DARPA ) utilizó ACE-89 como una oportunidad de inserción de tecnología al financiar el despliegue de Internet de Simulación de Defensa (DSI). Su video-teleconferencia empaquetada puso a los oficiales generales de las naciones de la OTAN cara a cara durante un ejercicio militar por primera vez; esto fue bien recibido. Pero la aplicación de software de DSI, distribución de Ground Warfare Simulation (GRWSIM), tuvo menos éxito. La simulación GRWSIM no fue confiable y su base de datos distribuida fue inconsistente, degradando la efectividad del ejercicio.
DARPA estaba financiando el desarrollo de un sistema de entrenamiento de tanques distribuido llamado SIMNET donde los entrenadores de tripulantes de tanques computarizados individuales estaban conectados a través de redes de área local y el DSI para cooperar en un solo campo de batalla virtual. El éxito de SIMNET, la decepción de ACE-89 y el deseo de combinar las simulaciones de combate existentes llevaron a DARPA a iniciar una investigación que conduzca a ALSP.
Principios básicos
DARPA patrocinó el diseño de una interfaz general entre grandes simulaciones de combate existentes a nivel agregado. Las simulaciones de combate de nivel agregado utilizan modelos de combate de Lanchestrian en lugar de modelos de armas físicas individuales y generalmente se usan 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 salir de un ejercicio sin restricciones.
- Distribución geográfica. Las simulaciones pueden residir en diferentes ubicaciones geográficas pero ejercitarse sobre el mismo terreno lógico.
- Entidades autónomas. Cada simulación controla sus propios recursos, dispara sus propias armas y, cuando se golpea uno de sus objetos, realiza una evaluación de daños localmente.
- Comunicación mediante transmisión 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 más allá de los de SIMNET:
- Gestión del tiempo de simulación. Normalmente, el tiempo de simulación es independiente del tiempo del reloj de pared. Para que los resultados de una simulación distribuida sean "correctos", el tiempo debe ser coherente en todas las simulaciones. [1]
- Gestión de datos. Los esquemas para la representación del estado interno difieren entre las simulaciones existentes, lo que requiere un sistema de representación común y mecanismos de mapeo y control concomitantes.
- Independencia de la arquitectura. Las características arquitectónicas (lenguaje de implementación, interfaz de usuario y mecanismo de flujo de tiempo) de las simulaciones existentes diferían. La arquitectura implícita en ALSP debe ser discreta para las arquitecturas existentes.
Marco conceptual
Un marco conceptual es una estructura organizativa de conceptos que facilita el desarrollo del modelo de simulación. [2] Los marcos conceptuales comunes incluyen: programación de eventos, escaneo de actividades e interacción de procesos.
El marco conceptual ALSP se basa en objetos, donde un modelo se compone de objetos que se caracterizan por atributos a los que se asignan valores. Las clases de objetos se organizan jerárquicamente de la misma manera que con los lenguajes de programación orientados a objetos. ALSP admite una confederación de simulaciones que se coordinan utilizando un modelo común.
Para diseñar un mecanismo que permita la interacción de las simulaciones existentes, son posibles dos estrategias: (1) definir una infraestructura que se traduzca entre las representaciones en cada simulación, o (2) definir un esquema de representación común y requerir que todas las simulaciones se mapeen en ese esquema.
La primera estrategia requiere pocas perturbaciones en las simulaciones existentes; la interacción se facilita íntegramente a través de la infraestructura de interconexión. Sin embargo, esta solución no se escala bien. Debido a un requisito subyacente de escalabilidad, el diseño de ALSP adoptó la segunda estrategia. ALSP prescribe que cada simulación se mapea 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 se debe modificar una simulación 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 de avance de tiempo interno de la simulación para que funcione de manera cooperativa con las demás simulaciones dentro de la confederación.
En las simulaciones independientes, los objetos entran (y desaparecen) con el paso del tiempo de simulación y la disposición de estos objetos es únicamente el ámbito de la simulación. Cuando se actúa dentro de una confederación, la relación simulación-objeto es más complicada.
La propiedad de propiedad del objeto de simulación es dinámica, es decir, durante su vida útil, un objeto puede ser propiedad de 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 "identificativo" del objeto. Poseer un atributo de un objeto significa que una simulación es responsable de calcular y reportar cambios en el valor del atributo. Los objetos que no pertenecen a una simulación en particular pero que están dentro del área de percepción de la simulació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 este hecho a la confederación para permitir que otras simulaciones creen fantasmas. Asimismo, cuando una simulación elimina un objeto, informa de este hecho para habilitar la eliminación de fantasmas. Siempre que una simulación realiza una acción entre uno de sus objetos y un fantasma, la simulación debe informar de ello a la confederación. En el lenguaje de ALSP, esto es una interacción. Estos conceptos fundamentales proporcionan la base para el resto de la presentación. El término modelo de confederación describe la jerarquía de objetos, los atributos y las interacciones que respalda una confederación.
Software de infraestructura ALSP (AIS)
El marco conceptual basado en objetos adoptado por ALSP define clases de información que deben distribuirse. El software de infraestructura ALSP (AIS) proporciona distribución de datos y coordinación de procesos. Los componentes principales de AIS son el módulo común ALSP (ACM) y el emulador de difusión ALSP (ABE).
Módulo común ALSP (ACM)
El módulo común 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 administración de tiempo y administración de objetos; Incluyen:
- Coordinar simulaciones de entrada y salida de una confederación.
- Coordinar la simulación de la hora local con la hora de la confederación.
- Filtre los mensajes entrantes, para que las simulaciones reciban solo mensajes de interés.
- Coordinar la propiedad de los atributos de los objetos y permitir la migración de la propiedad.
- Haga cumplir la propiedad de los atributos para que las simulaciones informen valores solo para los atributos que poseen.
Gestión del tiempo
Unirse y salir de una confederación es una 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 sale de una confederación, los otros ACM eliminan las colas de mensajes de entrada para esa simulación.
Las instalaciones de gestión del tiempo de ALSP admiten la simulación de eventos discretos mediante mecanismos de avance de tiempo asíncronos (siguiente evento) o síncronos (escalonados en el tiempo). [3] El mecanismo para respaldar las simulaciones del próximo evento es
- Una simulación envía un mensaje de solicitud de evento a su ACM con un parámetro de tiempo correspondiente 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 más nuevas que T, el ACM envía un avance de concesión a la simulación, dándole permiso para procesar su evento local en el tiempo T.
- La simulación envía cualquier mensaje resultante del evento a su ACM.
- La simulación se repite desde el paso (1).
El mecanismo para respaldar la simulación escalonada en el tiempo es:
- La simulación procesa todos los eventos durante un intervalo de tiempo. .
- La simulación envía una solicitud anticipada a su ACM por tiempo .
- El ACM envía todos los mensajes con marcas de tiempo en el intervalo a la simulación, seguida de una subvención-anticipo a T +? T.
- La simulación envía cualquier mensaje para el intervalo al ACM.
- La simulación se repite desde el paso (1).
AIS incluye un mecanismo de evitación de interbloqueo mediante mensajes nulos. El mecanismo requiere que los procesos tengan características de anticipación explotables .
Gestión de objetos
El ACM administra la base de datos de atributos y la información del filtro. La base de datos de atributos mantiene los objetos conocidos por la simulación, ya sean propios o fantasma, y los atributos de esos objetos que la simulación posee actualmente. Para cualquier clase de objeto, los atributos pueden ser miembros de
- Crear conjunto. Atributos mínimamente necesarios para representar un objeto
- Interés establecido. 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 se puede restringir aún más mediante filtros. El filtrado proporciona discriminación por (1) clase de objeto, (2) valor o rango de atributo y (3) ubicación geográfica. Los filtros también definen las interacciones relevantes para una simulación.
Si (una actualización pasa todos los criterios de filtro)| Si (el objeto es conocido por la simulación)| | Enviar nuevos valores de atributos a la simulación.| Else (el objeto es desconocido)| | Si (hay suficiente información para crear un fantasma)| | | Envíe un mensaje de creación a la simulación| | De lo contrario (no se conoce suficiente información)| | | Información de la tienda proporcionada| | | Envíe una solicitud a la confederación por los datos faltantesDe lo contrario (la actualización falla en los criterios de filtrado)| Si (el objeto es conocido por la simulación)| | Enviar un mensaje de eliminación a la simulación.| Demás| | Descartar los datos de actualización
La información de propiedad y filtrado que mantiene el 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 retransmite el mensaje en todas sus rutas de comunicación restantes. Esto permite configuraciones en las que todos los componentes ALSP son locales entre sí (en la misma computadora o en una red de área local). También permite configuraciones en las que 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 consiste en (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 de simulación a simulación, 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 comunicaciones entre componentes fue dictada por los requisitos de simulación y las interfaces de la capa de transporte en los sistemas operativos compatibles con AIS: las plataformas VMS locales utilizaron buzones de correo compartidos; las plataformas VMS no locales utilizaban DECnet transparente o TCP / IP; y las plataformas similares a UNIX utilizan TCP / IP.
Protocolo ALSP
El protocolo ALSP se basa en un conjunto de cuestiones ortogonales que comprenden el espacio de problemas de ALSP: comunicación de simulación a simulación, gestión de objetos y gestión del tiempo. Estos problemas se abordan mediante un protocolo en capas que tiene en la parte superior un protocolo de simulación con protocolos subyacentes 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:
- Actualizar. Los objetos en ALSP se definen mediante un número de identificación único, una clase y un conjunto de atributos asociados con un c1ass. A medida que una simulación cambia el estado de sus objetos, envía mensajes de actualización al ACM que proporcionan valores de atributo iniciales o modificados. El ACM luego distribuye la información a través de AIS a otras simulaciones que han mostrado interés.
- Interacción. Las interacciones entre objetos se identifican por tipo. Los tipos de interacción se describen mediante parámetros, al igual que los objetos se describen mediante atributos. Cuando el objeto de una simulación se relaciona con el objeto de otra simulación o con un área geográfica, la simulación envía un mensaje de interacción al ACM para su posterior difusión a otras simulaciones interesadas.
- Actualizar solicitud. Una simulación puede solicitar una 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.
- Borrar. Cuando una simulación hace que uno de sus objetos deje de existir, la simulación envía un mensaje de eliminación para informar a otras simulaciones.
El protocolo de simulación está basado en texto. Está definido por 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 tanto, la representación sintáctica del protocolo de simulación puede definirse sin un conocimiento a priori de la semántica de los objetos y las interacciones de cualquier confederación en particular.
Protocolo de conexión de simulación / ACM
El protocolo de conexión de simulación / ACM proporciona servicios para gestionar la conexión entre una simulación y su ACM y un método de intercambio de información entre una simulación y su ACM. Dos servicios controlan la distribución de los mensajes del protocolo de simulación: eventos y despachos. Los mensajes de eventos tienen una marca de tiempo y se entregan en un orden temporal coherente. Los mensajes de despacho se entregan lo antes posible, sin tener en cuenta el tiempo de simulación. Los mensajes de protocolo adicionales proporcionan servicios de estado de conexión, registro de filtros, control de bloqueo de atributos, control de guardado de confederación, control de recursos de objetos y control de tiempo.
Protocolo de gestión de objetos
El protocolo de gestión de objetos es un protocolo a nivel de pares que se encuentra por debajo del protocolo de simulación y proporciona servicios de gestión de objetos. Los ACM lo utilizan únicamente 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 que AIS administre la propiedad de objetos distribuidos.
La propiedad de objetos distribuidos presupone que ninguna simulación debe poseer todos los objetos de una confederación, pero muchas simulaciones requieren el conocimiento de algunos objetos. Una simulación utiliza mensajes de actualización del protocolo de simulación para descubrir objetos que pertenecen a otras simulaciones. Si esta simulación está interesada en los objetos, puede utilizarlos como fantasmas (rastrear sus ubicaciones y estado) y modelar interacciones con ellos desde los objetos de su propiedad.
Las cerraduras implementan la propiedad de los atributos. Una función principal del protocolo de gestión de objetos es garantizar que una simulación solo actualice los atributos para los que ha adquirido un bloqueo. El administrador de objetos en el ACM administra los objetos y los atributos de los objetos de propiedad y fantasma conocidos por el ACM. Los servicios proporcionados por el protocolo de simulación / ACM son utilizados por las simulaciones para interactuar con el mecanismo de bloqueo de atributos del ACM. La coordinación de estado, solicitud, adquisición y liberación de atributos de objeto, entre ACM, utiliza el protocolo de gestión de objetos. Cada atributo de cada objeto conocido por un ACM dado tiene un estado que asume uno de tres valores:
- Bloqueado. Una simulación controla el atributo y puede actualizar el valor del atributo. Una simulación "posee" el atributo si tiene ese atributo bloqueado. Una simulación "posee" el objeto si tiene su atributo id bloqueado.
- Desbloqueado. Actualmente, ninguna simulación controla el atributo. Se le concede el control a cualquier simulación que solicite control.
- Desaparecido. El estado de control se mantiene en otras partes de la confederación.
Desde la perspectiva del ACM, los objetos surgen a través del proceso de registro realizado por su simulación o mediante el descubrimiento de objetos registrados por otras simulaciones. Los bloqueos de atributo de estado inicial para objetos registrados y objetos descubiertos son los siguientes:
- El registro de objetos coloca cada par objeto-atributo en el estado bloqueado. La simulación puede especificar opcionalmente atributos para estar en el estado desbloqueado.
- Object Discovery agrega un objeto a la base de datos de objetos como un objeto fantasma. Todos los atributos de este objeto están marcados con un estado de desaparecido.
Protocolo de gestión de tiempo
El protocolo de gestión del tiempo también es un protocolo a nivel de pares que se encuentra 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 proporciona servicios para la coordinación distribuida de la entrada de una simulación a la confederación, la progresión del tiempo y los ahorros de confederación.
Los servicios de unión / renuncia y los mecanismos de sincronización de tiempo se describen en la Sección anterior. El mecanismo de guardado proporciona tolerancia a errores. Se requiere coordinación para producir una instantánea consistente de todos los ACM, traductores y simulaciones para un valor particular de tiempo de simulación.
Filtrado de mensajes
El ACM utiliza el filtrado de mensajes de simulación para evaluar el contenido de un mensaje recibido de la confederación. El ACM entrega a su simulación mensajes que son de interés, y pasa criterios de filtrado y descarta aquellos que no son de interés. El ACM filtra dos tipos de mensajes: mensajes de actualización y mensajes de interacción.
Actualizar mensajes. El ACM evalúa los mensajes de actualización en función de los criterios de filtrado de mensajes de actualización de la simulación que proporciona la simulación. Como se discutió anteriormente, cuando un ACM recibe un mensaje de actualización, hay 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 el 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. El parámetro kind tiene una estructura jerárquica similar a la estructura de clases de objetos. La simulación informa a su ACM de los tipos de interacción que deberían pasar o no el filtro de interacción.
Distribución de mensajes
Para minimizar el tráfico de mensajes entre los componentes de 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 del 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 que los ACM solo distribuyan datos sobre clases (y atributos de clases) que sean de interés para la confederación. La ABE también utiliza esta información para enviar solo información que sea de interés para los componentes a los que sirve. Para los mensajes de interacción, el proceso es similar, excepto que el parámetro tipo en el mensaje de interacción determina dónde se envía el mensaje.
Otras lecturas
- Anita Adams, Gordon Miller y David Seidel, noviembre de 1993, "Informe anual de la Confederación de 1993 del Protocolo de simulación de nivel agregado (ALSP)" , The MITRE Corporation. Una 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 conjunta de capacitación (JTC)" , 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 Conjunta de Capacitación: Implicaciones para el desarrollo futuro" , 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, "Unirse a un entorno de simulación distribuida 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 de protocolo de simulación de nivel agregado (ALSP)" , de marzo de 1995, The MITRE Corporation. Una historia del programa ALSP en el año fiscal 1994.
- Mary C. Fischer, abril de 1994, "Protocolo de simulación de 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. Un documento presentado en la Conferencia de Internet Elecsim de 1994 .
- Mary C. Fischer, Anita Adams, Gordon Miller, junio de 1994, "Protocolo de simulación de nivel agregado (ALSP) - Entrenamiento para el futuro" , Comando de simulación, entrenamiento e instrumentación del Ejército de los EE. UU. Y The MITRE Corporation. Un artículo presentado en la reunión del Simposio 62 de Investigación de Operaciones Militares en la Academia de la Fuerza Aérea en Colorado Springs, Colorado.
- Mary C. Fischer, diciembre de 1994, "Protocolo de simulación de 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. Un artículo presentado en la Conferencia de simulación de invierno de 1994 en Orlando, Florida.
- Mary C. Fischer, abril de 1995, "Protocolo de simulación de nivel agregado (ALSP) - Entrenamiento futuro con simulaciones interactivas distribuidas" , Comando de simulación, entrenamiento e instrumentación del Ejército de los EE. UU. Documento presentado en la Conferencia Internacional sobre Equipos de Formación 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" , Comando de simulación, entrenamiento e instrumentación del ejército de los EE. UU., Publicado en Actas del 36º seminario sobre modelado y simulación del Grupo de Investigación de Defensa (DRG) , 5 a 8 de septiembre de 1995, Washington, corriente continua
- Mary C. Fischer, octubre de 1995, "Campo de batalla simulado conjunto a través del protocolo de simulación de nivel agregado" , Comando de simulación, entrenamiento e instrumentación del Ejército de los EE. UU., Publicado en Proceedings of the Southeastern Simulation Conference '95 , Orlando, FL.
- Mary C. Fischer, marzo de 1996, "Confederación Conjunta de Entrenamiento" , Comando de Simulación, Entrenamiento e Instrumentación del Ejército de EE.UU., publicado en Actas de la Primera Conferencia Internacional de 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, "Proporcionar formación ininterrumpida a la Confederación conjunta de formación (JTC) durante la transición a la arquitectura de alto nivel (HLA)" , Actas de la formación y tecnología de simulación de 1997 (SimTecT) Conference , Canberra, Australia, 17-20 de marzo de 1997.
- George J. McFadden, "An Approach to Management of Enumerated Data in Federations" , 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, "The Joint Training Confederation and the Aggregate Level Simulation Protocol" , 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". Transacciones ACM sobre modelado y simulación por computadora . CiteSeerX 10.1.1.37.1829 .
- David L. Prochnow; Ernest H. Page; Mary C. Fischer (3 a 7 de marzo de 1997). "Gestión de la Familia de Especificaciones de la Confederación Conjunta de Formación". 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 distribuida para el entrenamiento militar" , Actas del Taller de interoperabilidad de simulación de primavera de 1997 , Orlando, FL, 3 a 7 de marzo de 1997.
- David L. Prochnow; Ernest H. Page; Bryan Youmans (9 a 13 de marzo de 1998). "Desarrollo de una herramienta de gestión de la federación: 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 del Protocolo de simulación de nivel agregado (ALSP)" , The MITRE Corporation. Una historia del programa ALSP desde su inicio en 1989 hasta 1992.
- John Tufarolo y Ernest Page, "Evolving the VV&A Process for the 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 de nivel agregado" , The MITRE Corporation. Un artículo presentado en la Conferencia de Verano de Simulación por Computadora 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. Un artículo presentado en la Conferencia de Invierno de 1993 sobre Simulación por Computadora 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 a través del Protocolo de simulación de nivel agregado" . Actas de HICSS-29: 29ª Conferencia Internacional de Hawaii sobre Ciencias de Sistemas . págs. 407 . CiteSeerX 10.1.1.37.4784 . doi : 10.1109 / HICSS.1996.495488 . ISBN 0-8186-7324-9. Parámetro desconocido
|conference=
ignorado ( ayuda ) - Annette Wilson y Richard Weatherly, abril de 1994, "Nuevas herramientas de gestión y reducción del tráfico para las confederaciones ALSP" , The MITRE Corporation. Un documento presentado en la Conferencia de Internet Elecsim de 1994 .
- Annette Wilson y Richard Weatherly, diciembre de 1994, "El protocolo de simulación de nivel agregado: un sistema en evolución" , The MITRE Corporation. Un artículo presentado en la Conferencia de simulación de invierno de 1994 en Orlando, Florida.
Referencias
- ^ Lamport, L. (1978). "Tiempo, relojes y ordenación de eventos en un sistema distribuido", Communications of the ACM, 21 (7), págs. 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). "Mecanismos de flujo de tiempo para simulaciones de eventos discretos", Management Science, 18 (l), págs. 59-93, septiembre.
- ^ Boggs, DR Shoch, JF, Taft, EA y Metcalfe, RM (1979). "PUP: An Internetwork Architecture", Informe CSL-79-10, XEROX Palo Alto Research Center, 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.