La simulación en vivo, virtual y constructiva ( LVC ) es una taxonomía ampliamente utilizada para clasificar el modelado y la simulación (M&S). Sin embargo, categorizar una simulación como un entorno en vivo, virtual o constructivo es problemático ya que no existe una división clara entre estas categorías. El grado de participación humana en una simulación es infinitamente variable, al igual que el grado de realismo del equipo. La categorización de las simulaciones también carece de una categoría para personas simuladas que trabajan con equipos reales. [1]
Las categorías LVC según las define el Departamento de Defensa de los Estados Unidos en el Glosario de modelado y simulación [2] son las siguientes:
Otros términos asociados son los siguientes:
Otras definiciones utilizadas en las discusiones sobre LVC (diccionario Webster)
La tecnología actual y emergente que permite la verdadera tecnología LVC para el entrenamiento de las Fuerzas Aéreas de Combate ("CAF") requiere que se debatan y desarrollen definiciones estandarizadas de los eventos LVC de las CAF. Los términos del diccionario utilizados anteriormente proporcionan una base sólida para comprender la estructura fundamental del tema LVC tal como se aplica universalmente a las actividades del Departamento de Defensa. Los términos y casos de uso que se describen a continuación son una guía para la doctrina que utiliza estos términos para eliminar cualquier malentendido. El párrafo siguiente utiliza estos términos para presentar la visión global y se explicará en detalle a lo largo del resto del documento. En resumen:
El entrenamiento y las pruebas operativas se llevan a cabo mediante el uso combinado de tres entornos independientes (en vivo, simulador y auxiliar), que a su vez están compuestos por varios componentes que permiten preparar, probar y/o entrenar a los combatientes en sus respectivas disciplinas. La empresa LVC, un componente del entorno en vivo, es la totalidad de personal, hardware y software que permite a los combatientes combinar tres entornos históricamente dispares (en vivo, virtual y constructivo) para mejorar el rendimiento en su función de combate.
Para una comprensión funcionalmente precisa del párrafo anterior es fundamental un conocimiento práctico de las definiciones de Medio Ambiente, que se proporcionan a continuación para mayor claridad:
Los entornos (L, V y C) por sí mismos son generalmente bien comprendidos y se aplican universalmente a una amplia gama de disciplinas, como el campo médico, la aplicación de la ley o las aplicaciones militares operativas. Si tomamos el campo médico como ejemplo, el entorno en vivo puede ser un médico que realiza RCP a un paciente humano en una situación crítica del mundo real. En este mismo contexto, el entorno virtual incluiría a un médico que practica RCP en un maniquí de entrenamiento, y el entorno constructivo es el software dentro del maniquí de entrenamiento que impulsa su comportamiento. En un segundo ejemplo, considere el entrenamiento de pilotos de combate o las pruebas operativas. El entorno en vivo es el piloto que vuela el avión de combate. El entorno virtual incluiría a ese mismo piloto volando un simulador. El entorno constructivo incluye las redes, las fuerzas generadas por computadora y los servidores de armas, etc. que permiten que los entornos en vivo y virtual se conecten e interactúen. Aunque claramente existen beneficios de entrenamiento secundarios y terciarios, es importante entender que la combinación de uno o más entornos con el propósito de mejorar el rendimiento en el mundo real es la única razón por la que se creó el concepto LVC. Sin embargo, cuando se hace referencia a actividades o programas específicos diseñados para integrar los entornos de toda la empresa, el uso y la aplicación de los términos difieren ampliamente en todo el Departamento de Defensa. Por lo tanto, las palabras que describen específicamente cómo se realizarán las futuras capacitaciones o pruebas operativas también requieren estandarización. Esto se describe mejor si nos alejamos de la terminología técnica y pensamos en cómo se preparan realmente los seres humanos para sus responsabilidades específicas de combate. En la práctica, los seres humanos se preparan para sus funciones en uno de tres constructos: en vivo (con herramientas de combate reales), en un simulador de algún tipo o de otras formas auxiliares (pruebas, académicos, capacitación basada en computadora, etc.). Las acciones dentro de cada uno de los constructos se desglosan a su vez en componentes que especifican diferentes formas de hacer el trabajo o alcanzar los objetivos de capacitación. Los tres constructos se describen a continuación:
Live es uno de los tres constructos que representan a los seres humanos que operan el sistema operativo de sus respectivas disciplinas. Los ejemplos de sistemas operativos podrían consistir en un tanque, un buque de guerra, una aeronave o, eventualmente, incluso un hospital quirúrgico desplegado. Tres componentes del constructo Live son los siguientes:
El simulador es una combinación de lo virtual y lo constructivo (VC) y está compuesto por personas que operan dispositivos simulados en lugar de sistemas operativos en vivo. El simulador consta de tres componentes:
¿Es el tercer constructo distinto de Live o Simulator en el que el entrenamiento se realiza a través de muchos componentes (no todos incluidos)?
Utilizando las definiciones anteriores, la siguiente tabla proporciona una representación gráfica de cómo se relacionan los términos en el contexto del entrenamiento o la prueba operativa de CAF:
Si tomamos como guía la figura anterior, queda claro que la actividad LVC consiste en utilizar los entornos virtuales y constructivos para mejorar la complejidad del escenario para el entorno en vivo, y nada más. Un sistema LVC debe tener un sistema de comunicación bidireccional, adaptable, ad-hoc y seguro entre el entorno en vivo y el entorno VC. Lo más importante es que LVC utilizado como verbo es una interacción integrada de los tres entornos con el entorno en vivo siempre presente. Por ejemplo, un evento VC de construcción de simulador debería tener un nombre distinto a LVC (como Operaciones de misión distribuida (DMO)). En ausencia del entorno en vivo, LVC y LC no existen, lo que hace que el uso del término LVC sea totalmente inadecuado como descriptor.
Como la Empresa LVC se refiere a un programa de entrenamiento, las líneas de esfuerzo LVC se definen correctamente como “una colaboración de los esfuerzos de OSD, HAF, MAJCOM, Joint y Coalition hacia un camino tecnológicamente sólido y fiscalmente responsable para el entrenamiento que permita la preparación para el combate”. Las “líneas de esfuerzo”, en este caso, no incluirían los programas y el desarrollo de Simulator Construct, sino que se limitarían al Construct que incluye la Empresa LVC. El otro término común, “Hacer LVC”, implicaría entonces “entrenamiento de preparación realizado utilizando una integración de activos virtuales y constructivos para aumentar los escenarios del sistema operativo en vivo y los resultados de los objetivos de la misión”. Del mismo modo, el Entrenamiento Operacional LVC (en un contexto de entrenamiento de combate de la CAF) o “LVC-OT” son las herramientas y el esfuerzo necesarios para integrar sistemas de misión en vivo, virtuales y constructivos, cuando sea necesario, para adaptar métodos robustos y rentables de Entrenamiento Operativo y/o Prueba.
Para garantizar la claridad de las discusiones y eliminar los malentendidos, cuando se habla en el contexto de LVC, solo se deben utilizar los términos de este documento para describir los entornos, las construcciones y los componentes. Las palabras como "sintético" y "digital" deben reemplazarse por "constructivo" o "virtual". Además, los sistemas de entrenamiento integrado (ET), definidos como un sistema local o autónomo en vivo/constructivo (como en el F-22 o el F-35), no deben confundirse con los sistemas LVC ni referirse a ellos como tales.
Antes de 1990, el campo de M&S se caracterizaba por la fragmentación y la coordinación limitada entre las actividades de las comunidades clave. En reconocimiento de estas deficiencias, el Congreso ordenó al Departamento de Defensa (DoD) “... establecer una oficina de programa conjunto a nivel de la Oficina del Secretario de Defensa (OSD) para la simulación con el fin de coordinar la política de simulación, establecer estándares y protocolos de interoperabilidad, promover la simulación dentro de los departamentos militares y establecer pautas y objetivos para la coordinación [sic] de la simulación, los juegos de guerra y el entrenamiento”. (ref. Informe del Comité de Autorización del Senado, año fiscal 91, Proyecto de ley de asignaciones del DoD, SR101-521, págs. 154-155, 11 de octubre de 1990) En consonancia con esta dirección, se creó la Oficina de Simulación y Modelado de Defensa (DMSO), y poco después muchos componentes del DoD designaron organizaciones y/o puntos de contacto para facilitar la coordinación de las actividades de M&S dentro y entre sus comunidades. Durante más de una década, el objetivo final del Departamento de Defensa en materia de M&S ha sido crear un entorno de LVC-IA para ensamblar modelos y simulaciones rápidamente, que creen un entorno de LVC válido desde el punto de vista operativo para entrenar, desarrollar doctrina y tácticas, formular planes operativos y evaluar situaciones de guerra. Un uso común de estos entornos de LVC promoverá una interacción más estrecha entre las comunidades de operaciones y adquisiciones. Estos entornos de M&S se construirán a partir de componentes componibles que interoperarán a través de una arquitectura integrada. Una capacidad de M&S sólida permite al Departamento de Defensa cumplir con los objetivos operativos y de apoyo de manera efectiva en las diversas actividades de los servicios militares, los comandos combatientes y las agencias. [5] [6]
La cantidad de arquitecturas disponibles ha aumentado con el tiempo. Las tendencias de M&S indican que una vez que se desarrolla una comunidad de uso en torno a una arquitectura, es probable que esa arquitectura se utilice independientemente de los nuevos desarrollos arquitectónicos. Las tendencias de M&S también indican que pocas arquitecturas, si es que hay alguna, se retirarán a medida que entren en funcionamiento otras nuevas. Cuando se crea una nueva arquitectura para reemplazar una o más del conjunto existente, el resultado probable es que se agregue una arquitectura más al conjunto disponible. A medida que aumenta la cantidad de eventos de arquitectura mixta con el tiempo, también aumenta el problema de la comunicación entre arquitecturas. [7]
M&S ha logrado avances significativos al permitir a los usuarios vincular recursos críticos a través de arquitecturas distribuidas.
A mediados de los años 1980, SIMNET se convirtió en la primera implementación exitosa de una red de simuladores en tiempo real, a gran escala y con interacción humana para el entrenamiento de equipos y el ensayo de misiones en operaciones militares. El primer éxito que se logró con el programa SIMNET fue la demostración de que los sistemas de simulación geográficamente dispersos podían respaldar el entrenamiento distribuido al interactuar entre sí a través de conexiones de red. [8]
El Protocolo de Simulación a Nivel Agregado (ALSP, por sus siglas en inglés) extendió los beneficios de la simulación distribuida a la comunidad de entrenamiento a nivel de fuerza, de modo que diferentes simulaciones a nivel agregado pudieran cooperar para brindar experiencias a nivel de teatro de operaciones para el entrenamiento del personal de batalla. El ALSP ha respaldado una “confederación de modelos” en evolución desde 1992, que consiste en una colección de software de infraestructura y protocolos tanto para la comunicación entre modelos a través de una interfaz común como para el avance en el tiempo utilizando un algoritmo conservador basado en Chandy-Misra. [9]
Casi al mismo tiempo, el protocolo SIMNET evolucionó y maduró hasta convertirse en el estándar de simulación interactiva distribuida (DIS). DIS permitió que un mayor número de tipos de simulación interactuaran en eventos distribuidos, pero se centró principalmente en la comunidad de entrenamiento a nivel de plataforma. DIS proporcionó un estándar de protocolo de red abierto para vincular simulaciones de juegos de guerra a nivel de plataforma en tiempo real. [10]
A mediados de los años 90, la Oficina de Simulación y Modelado de Defensa (DMSO) patrocinó la iniciativa de Arquitectura de Alto Nivel (HLA). Diseñada para respaldar y reemplazar tanto a DIS como a ALSP, se iniciaron esfuerzos de investigación para crear un prototipo de infraestructura capaz de respaldar estas dos aplicaciones dispares. La intención era combinar las mejores características de DIS y ALSP en una única arquitectura que también pudiera respaldar usos en las comunidades de análisis y adquisición, al tiempo que seguía respaldando aplicaciones de capacitación.
La comunidad de pruebas del Departamento de Defensa comenzó a desarrollar arquitecturas alternativas basándose en su percepción de que la HLA ofrecía un rendimiento inaceptable e incluía limitaciones de fiabilidad. La comunidad de campos de pruebas en tiempo real comenzó a desarrollar la arquitectura de habilitación de pruebas y entrenamiento (TENA) para proporcionar un servicio de baja latencia y alto rendimiento en la aplicación en tiempo real estricta de integración de activos en vivo en el entorno de campo de pruebas. TENA, a través de su infraestructura común, que incluye el middleware de TENA y otros componentes de arquitectura complementarios, como el repositorio de TENA, el archivo de campos lógicos y otras utilidades y herramientas de TENA, proporciona la arquitectura y la implementación de software y las capacidades necesarias para permitir de forma rápida y económica la intercambiabilidad entre sistemas de campos, instalaciones y simulaciones. [11] [12] [13]
De manera similar, el Ejército de los EE. UU. inició el desarrollo de la Arquitectura de Instrumentación de Entrenamiento Común (CTIA, por sus siglas en inglés) para vincular una gran cantidad de activos en vivo que requieren un conjunto de datos relativamente limitado con el fin de proporcionar Revisiones Posteriores a la Acción (AAR, por sus siglas en inglés) en campos de entrenamiento del Ejército en apoyo de ejercicios a gran escala. [14]
Otros esfuerzos que hacen que el espacio de la arquitectura LVC sea más complejo incluyen paquetes de software de intercambiabilidad universal como OSAMS [15] o CONDOR [16] desarrollados y distribuidos por proveedores comerciales.
A partir de 2010, todas las arquitecturas del Departamento de Defensa siguen en servicio, con excepción de SIMNET. De las arquitecturas restantes: CTIA, DIS, HLA, ALSP y TENA, algunas se encuentran en una fase inicial y de uso creciente (por ejemplo, CTIA, TENA), mientras que otras han experimentado una reducción de la base de usuarios (por ejemplo, ALSP). Cada una de las arquitecturas proporciona un nivel aceptable de capacidad dentro de las áreas en las que se han adoptado. Sin embargo, las federaciones basadas en DIS, HLA, TENA y CTIA no son inherentemente interoperables entre sí. Cuando las simulaciones dependen de diferentes arquitecturas, se deben tomar medidas adicionales para garantizar una comunicación eficaz entre todas las aplicaciones. Estos pasos adicionales, que normalmente implican la interposición de pasarelas o puentes entre las distintas arquitecturas, pueden introducir un mayor riesgo, complejidad, coste, nivel de esfuerzo y tiempo de preparación. Los problemas adicionales se extienden más allá de la implementación de eventos de simulación individuales. Como un solo ejemplo, la capacidad de reutilizar modelos de soporte, personal (experiencia) y aplicaciones en los diferentes protocolos es limitada. La interoperabilidad inherente limitada entre los diferentes protocolos introduce una barrera significativa e innecesaria para la integración de simulaciones en vivo, virtuales y constructivas.
El estado actual de la interoperabilidad de LVC es frágil y está sujeto a varios problemas recurrentes que deben resolverse (a menudo de nuevo) siempre que los sistemas de simulación en vivo, virtuales o constructivos sean componentes en un evento de simulación de arquitectura mixta. Algunos de los problemas asociados surgen de las limitaciones de capacidad del sistema de simulación y otras incompatibilidades entre sistemas. Otros tipos de problemas surgen de la falla general en proporcionar un marco que logre una interoperabilidad a nivel semántico más completa entre sistemas dispares. [17] La interoperabilidad, la integración y la componibilidad se han identificado como los aspectos técnicos más desafiantes de un LVC-IA desde al menos 1996. El Estudio sobre la efectividad del modelado y la simulación en el proceso de adquisición de sistemas de armas [18] también identificó desafíos culturales y de gestión. Por definición, un LVC-IA es un sistema técnico social , un sistema técnico que interactúa directamente con las personas. La siguiente tabla identifica los desafíos de 1996 asociados con los aspectos técnicos, culturales y de gestión. Además, también se incluyen los desafíos o brechas encontrados en un estudio de 2009. [19] La tabla muestra que hay poca diferencia entre los desafíos de 1996 y los desafíos de 2009.
Un modelo virtual o constructivo generalmente se enfoca en la fidelidad o precisión del elemento que se representa. Una simulación en vivo, por definición, representa la fidelidad más alta, ya que es la realidad. Pero una simulación rápidamente se vuelve más difícil cuando se crea a partir de varios elementos vivos, virtuales y constructivos, o conjuntos de simulaciones con varios protocolos de red, donde cada simulación consta de un conjunto de elementos vivos, virtuales y constructivos. Las simulaciones LVC son sistemas socio-técnicos debido a la interacción entre personas y tecnología en la simulación. Los usuarios representan a las partes interesadas de las comunidades de adquisición, análisis, prueba, capacitación, planificación y experimentación. M&S ocurre a lo largo de todo el ciclo de vida del Sistema de Desarrollo de Integración de Capacidades Conjuntas (JCID). Consulte la figura "M&S en el proceso JCID". Un LVC-IA también se considera un sistema de Ultra Gran Escala (ULS) debido al uso por parte de una amplia variedad de partes interesadas con necesidades conflictivas y la construcción en constante evolución a partir de partes heterogéneas. [20] Por definición, las personas no son solo usuarios sino elementos de una simulación LVC.
Durante el desarrollo de varios entornos LVC-IA, surgieron intentos de comprender los elementos fundamentales de la integración, la componibilidad y la interoperabilidad. A partir de 2010, nuestra comprensión de estos tres elementos aún está evolucionando, al igual que el desarrollo de software continúa evolucionando. Considere la arquitectura de software; como concepto, se identificó por primera vez en el trabajo de investigación de Edsger Dijkstra en 1968 y David Parnas a principios de la década de 1970. El área de arquitectura de software fue adoptada recientemente en 2007 por ISO como ISO/IEC 42010:2007. La integración se describe rutinariamente utilizando los métodos de patrones arquitectónicos y de software. Los elementos funcionales de la integración se pueden entender debido a la universalidad de los patrones de integración, por ejemplo, mediación (intracomunicación) y federación (intercomunicación); procesos, sincronización de datos y patrones de concurrencia .
Una LVC-IA depende de los atributos de interoperabilidad y componibilidad, no solo de los aspectos técnicos, sino también de los aspectos sociales o culturales. Existen desafíos sociotécnicos, así como desafíos del sistema ULS asociados con estas características. Un ejemplo de un aspecto cultural es el problema de la validez de la composición. En un ULS, la capacidad de controlar todas las interfaces para garantizar una composición válida es extremadamente difícil. Los paradigmas VV&A se enfrentan al desafío de identificar un nivel de validez aceptable.
El estudio de la interoperabilidad se ocupa de las metodologías para interoperar diferentes sistemas distribuidos en un sistema de red. Andreas Tolk introdujo el Modelo de niveles de interoperabilidad conceptual (LCIM), que identificaba siete niveles de interoperabilidad entre los sistemas participantes como método para describir la interoperabilidad técnica y la complejidad de las interoperaciones. [21]
La teoría de modelado y simulación de Bernard Zeigler amplía los tres niveles básicos de interoperabilidad:
El nivel pragmático se centra en la interpretación que hace el receptor de los mensajes en el contexto de la aplicación en relación con la intención del emisor. El nivel semántico se ocupa de las definiciones y atributos de los términos y de cómo se combinan para proporcionar un significado compartido a los mensajes. El nivel sintáctico se centra en la estructura de los mensajes y en la adhesión a las reglas que rigen esa estructura. El concepto de interoperabilidad lingüística admite un entorno de pruebas simultáneas en varios niveles.
El LCIM asocia las capas inferiores con los problemas de interoperabilidad de la simulación, mientras que las capas superiores se relacionan con los problemas de reutilización y composición de los modelos. Concluye que “los sistemas de simulación se basan en modelos y sus supuestos y restricciones. Si se combinan dos sistemas de simulación, estos supuestos y restricciones deben alinearse en consecuencia para garantizar resultados significativos”. Esto sugiere que los niveles de interoperabilidad que se han identificado en el área de M&S pueden servir como pautas para el debate sobre el intercambio de información en general.
La arquitectura Zeigler proporciona un lenguaje de descripción de arquitectura o modelo conceptual en el que se puede analizar la arquitectura y los sistemas. El LCIM proporciona un modelo conceptual como medio para analizar la integración, la interoperabilidad y la componibilidad. Los tres elementos lingüísticos relacionan el LCIM con el modelo conceptual de Ziegler. La complejidad arquitectónica y estructural es un área de investigación en la teoría de sistemas para medir la cohesión y el acoplamiento y se basa en las métricas que se utilizan comúnmente en los proyectos de desarrollo de software. Zeigler, Kim y Praehofer presentan una teoría de modelado y simulación que proporciona un marco conceptual y un enfoque computacional asociado a los problemas metodológicos en la arquitectura y los sistemas. El marco proporciona un conjunto de entidades y relaciones entre las entidades que, en efecto, presentan una ontología del dominio de la arquitectura y los sistemas. [22]
Petty y Weisel [23] formularon la definición de trabajo actual: "La componibilidad es la capacidad de seleccionar y ensamblar componentes de simulación en varias combinaciones en sistemas de simulación para satisfacer requisitos específicos del usuario". Se requiere una interacción tanto técnica como de usuario, lo que indica que está involucrado un sistema sociotécnico. La capacidad de un usuario para acceder a datos o acceder a modelos es un factor importante al considerar métricas de componibilidad. Si el usuario no tiene visibilidad de un repositorio de modelos, la agregación de modelos se vuelve problemática.
En el artículo Mejorar la componibilidad de los modelos y simulaciones del Departamento de Defensa , los factores asociados con la capacidad de proporcionar componibilidad son los siguientes:
Tolk [25] introdujo una visión alternativa sobre la componibilidad, centrándose más en la necesidad de alineación conceptual:
La comunidad de M&S entiende muy bien la interoperabilidad como la capacidad de intercambiar información y utilizar los datos intercambiados en el sistema receptor. La interoperabilidad se puede diseñar en un sistema o servicio después de su definición e implementación.
La componibilidad es diferente de la interoperabilidad. La componibilidad es la representación consistente de la verdad en todos los sistemas participantes. Amplía las ideas de interoperabilidad añadiendo el nivel pragmático para cubrir lo que sucede dentro del sistema receptor en función de la información recibida. A diferencia de la interoperabilidad, la componibilidad no se puede diseñar en un sistema después de que se haya realizado. A menudo, la componibilidad requiere cambios significativos en la simulación.
En otras palabras: los conceptos con propiedad, si se modelan en más de un sistema participante, tienen que representar la misma verdad. No se permite que los sistemas componibles obtengan respuestas diferentes a la misma pregunta en ambos sistemas. El requisito de una representación consistente de la verdad reemplaza el requisito de un uso significativo de la información recibida conocida a partir de la interoperabilidad.
Page et al. [26] sugieren definir la integrabilidad como un asunto que se refiere a los ámbitos físicos y técnicos de las conexiones entre sistemas, que incluyen hardware y firmware, protocolos, redes, etc.; la interoperabilidad como un asunto que se refiere al software y los detalles de implementación de las interoperaciones; esto incluye el intercambio de elementos de datos a través de interfaces, el uso de middleware, el mapeo a modelos comunes de intercambio de información, etc.; y la componibilidad como un asunto que se refiere a la alineación de los problemas en el nivel de modelado. Como lo expresa, entre otros, Tolk [27], la interoperabilidad exitosa de soluciones de componentes LVC requiere la integrabilidad de las infraestructuras, la interoperabilidad de los sistemas y la componibilidad de los modelos . Las arquitecturas LVC deben abordar de manera holística los tres aspectos en enfoques sistémicos bien alineados.
Para que sus inversiones tengan el mayor impacto posible, el Departamento de Defensa debe gestionar sus programas de M&S utilizando un enfoque de tipo empresarial. Esto incluye tanto la identificación de las deficiencias en las capacidades de M&S que son comunes en toda la empresa y la provisión de capital inicial para financiar proyectos que tengan beneficios de amplia aplicación, como la realización de inversiones en M&S en todo el Departamento de manera sistemática y transparente. En particular, los “procesos de gestión de modelos, simulaciones y datos que… faciliten el desarrollo rentable y eficiente de los sistemas y capacidades de M&S…”, como los que se citan en la declaración de visión, requieren estrategias y procesos de inversión integrales de mejores prácticas en M&S del Departamento. La gestión de las inversiones en M&S requiere métricas, tanto para cuantificar el alcance de las inversiones potenciales como para identificar y comprender la gama completa de beneficios resultantes de estas inversiones. En este momento no existe una guía consistente para dicha práctica. [28]
Los costos de desarrollo y uso asociados con el LVC se pueden resumir de la siguiente manera: [29] [30]
En cambio, la fidelidad de M&S es más alta en el modo en vivo, más baja en el modo virtual y más baja en el modo constructivo. Como tal, la política del Departamento de Defensa es un uso mixto de LVC a lo largo del ciclo de vida de Adquisiciones Militares , también conocido como el Continuum LVC . En la figura del Continuum LVC a la derecha, el proceso JCIDS está relacionado con el uso relativo de LVC a lo largo del ciclo de vida de Adquisiciones Militares .
{{cite web}}: CS1 maint: archived copy as title (link){{cite web}}: CS1 maint: archived copy as title (link){{cite web}}: CS1 maint: archived copy as title (link){{cite web}}: CS1 maint: archived copy as title (link){{cite web}}: CS1 maint: archived copy as title (link)