Живой, виртуальный и конструктивный

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article may require cleanup to meet Wikipedia's quality standards. The specific problem is: Heading and subheading to be reformated. Please help improve this article if you can. (October 2014) (Learn how and when to remove this message) This article's lead section may be too short to adequately summarize the key points. Please consider expanding the lead to provide an accessible overview of all important aspects of the article. (March 2015) (Learn how and when to remove this message)

Живое, виртуальное и конструктивное ( LVC ) моделирование — это широко используемая таксономия для классификации моделирования и имитации (M&S). Однако категоризация моделирования как живой, виртуальной или конструктивной среды проблематична, поскольку нет четкого разделения между этими категориями. Степень человеческого участия в моделировании бесконечно изменчива, как и степень реалистичности оборудования. В классификации симуляций также отсутствует категория для симулированных людей, работающих с реальным оборудованием. [ ^1]

Категории LVC определены Министерством обороны США в Словаре терминов моделирования и имитации ^[2] следующим образом:

• Live - Моделирование с участием реальных людей, работающих с реальными системами. Военные учебные мероприятия с использованием реального оборудования являются реальными моделированиями. Они считаются моделированиями, поскольку не проводятся против живого противника.
• Виртуальный — симуляция с участием реальных людей, управляющих симулированными системами. Виртуальные симуляции вводят человека-в-контуре в центральную роль, тренируя навыки управления моторикой (например, симулятор полета на реактивном самолете или танке), навыки принятия решений (например, задействование ресурсов управления огнем в действиях) или навыки общения (например, в качестве членов команды C4I ).
• Конструктивный — симуляция, в которой участвуют симулированные люди, управляющие симулированными системами. Реальные люди стимулируют (вносят вклад) такие симуляции, но не участвуют в определении результатов. Конструктивная симуляция — это компьютерная программа. Например, военный пользователь может вводить данные, инструктирующие подразделение двигаться и поражать вражескую цель. Конструктивная симуляция определяет скорость движения, эффект от столкновения с противником и любые боевые повреждения, которые могут возникнуть. Эти термины не следует путать с конкретными конструктивными моделями, такими как Computer Generated Forces (CGF), общий термин, используемый для обозначения компьютерных представлений сил в симуляциях, которые пытаются моделировать поведение человека. CGF — это всего лишь один пример модели, используемой в конструктивной среде. Существует много типов конструктивных моделей, в которых участвуют симулированные люди, управляющие симулированными системами.

Другие сопутствующие термины:

• Предприятие LVC — совокупность ресурсов, в которых осуществляется деятельность LVC.
• Интеграция LVC — процесс связывания симуляций LVC с помощью подходящей технологии или протокола для использования взаимодействия симуляций в рамках федеративной среды симуляции, такой как HLA или EuroSim . ^{[3] [4]}
• Интегрирующая архитектура LVC ( LVC-IA ) — совокупное представление основных элементов предприятия LVC, включая оборудование , программное обеспечение , сети , базы данных и пользовательские интерфейсы , политики , соглашения, сертификации /аккредитации и бизнес-правила . LVC-IA по сути является архитектурой предприятия , учитывая среду «система-систем», которую она должна поддерживать. LVC-IA связывает технологию M&S с людьми, которым нужна и которые используют информацию, полученную с помощью моделирования . Для достижения этого LVC-IA обеспечивает следующее:
  • Интеграция через оборудование для моделирования, инструменты взаимодействия и вспомогательный персонал. См. также Интеграция предприятия и Архитектура предприятия . Интеграция создает сетецентрические связи для сбора, извлечения и обмена данными между живыми приборами , виртуальными симуляторами и конструктивными симуляциями, а также между совместными военными и специальными системами командования служб . Интеграция также объединяет управление данными , управление учениями , сотрудничество в учениях и обновление систем поддержки обучения.
  • Взаимодействие посредством общих протоколов , спецификаций , стандартов и интерфейсов для стандартизации компонентов и инструментов LVC для репетиций и обучения миссий , тестирования , приобретения , анализа , экспериментов и планирования логистики .
  • Возможность компоновки за счет общих и повторно используемых компонентов и инструментов, таких как корпоративный обзор после действий , адаптеры, коррелированные базы данных рельефа , многоуровневая безопасность для многонациональных игроков и требования к оборудованию/программному обеспечению.

Другие определения, используемые в обсуждениях LVC (словарь Вебстера)

1. Предприятие: проект или начинание, которое является особенно трудным, сложным или рискованным.
   • A: единица экономической организации или деятельности; в частности: бизнес-организация
   • B: систематическая целенаправленная деятельность
2. Окружающая среда: совокупность окружающих вещей, условий или влияний; окружение.
3. Конструировать: создавать или формировать путем комбинирования или расположения компонентов.
4. Компонент: Одна из частей чего-либо

Текущие и новые технологии, позволяющие реализовать настоящую технологию LVC для обучения боевых воздушных сил («CAF»), требуют обсуждения и разработки стандартизированных определений событий CAF LVC. Словарные термины, использованные выше, обеспечивают прочную основу для понимания фундаментальной структуры темы LVC, применяемой повсеместно к деятельности DoD. Термины и варианты использования, описанные ниже, являются ориентиром для доктрины, которая использует эти термины для устранения любого недопонимания. В следующем параграфе эти термины используются для компоновки глобального представления и будут подробно объяснены в остальной части документа. Короче говоря:

Обучение и эксплуатационные испытания проводятся посредством комбинированного использования трех отдельных конструкций (живой, имитатор и вспомогательный), которые в свою очередь состоят из нескольких компонентов, позволяющих готовить, тестировать и/или обучать бойцов в их соответствующих дисциплинах. LVC Enterprise, компонент живой конструкции, представляет собой совокупность персонала, оборудования и программного обеспечения, которая позволяет бойцам объединять три исторически разрозненные среды (живую, виртуальную и конструктивную) для улучшения производительности в своей боевой роли.

Центральным элементом функционально точного понимания приведенного выше параграфа является знание определений окружающей среды, приведенных ниже для ясности:

• Реальная среда (L)*: бойцы, использующие операционную систему своих дисциплин в реальных условиях
• Виртуальная среда (V)*: бойцы, использующие полевые симуляторы или тренажеры
• Конструктивная среда (C)*: компьютерно-генерируемые силы (CGF), используемые для усиления и ускорения развития реальных и/или виртуальных сценариев.

Окружения (L, V и C) сами по себе, как правило, хорошо понятны и применяются универсально в самых разных дисциплинах, таких как медицина, правоохранительные органы или оперативные военные приложения. Если использовать медицинскую сферу в качестве примера, то среда Live может быть врачом, выполняющим СЛР человеку-пациенту в критической ситуации реального мира. В этом же контексте виртуальная среда будет включать врача, практикующего СЛР на учебном манекене, а конструктивная среда — это программное обеспечение в учебном манекене, которое управляет его поведением. Во втором примере рассмотрим обучение летчиков-истребителей или эксплуатационные испытания. Среда Live — это пилот, управляющий боевым самолетом. Виртуальная среда будет включать того же пилота, управляющего симулятором. Конструктивная среда включает сети, компьютерные силы и серверы вооружения и т. д., которые позволяют средам Live и Virtual быть связанными и взаимодействовать. Хотя существуют явно вторичные и третичные преимущества обучения, важно понимать, что объединение одной или нескольких сред с целью повышения производительности в реальном мире Live является единственной причиной создания концепции LVC. Однако при упоминании конкретных видов деятельности или программ, разработанных для интеграции сред в масштабах предприятия, использование и применение терминов значительно различаются в DoD. Поэтому слова, которые конкретно описывают, как будет осуществляться будущее обучение или эксплуатационное тестирование, также требуют стандартизации. Это лучше всего описать, отойдя от технической терминологии и подумав о том, как люди на самом деле готовятся к своим конкретным боевым обязанностям. На практике люди готовятся к своим ролям в одной из трех конструкций: вживую (с реальными боевыми инструментами), в симуляторе какого-либо вида или другими вспомогательными способами (тесты, академические занятия, компьютерное обучение и т. д.). Действия в каждой из конструкций далее разбиваются на компоненты, которые определяют различные способы выполнения работы или достижения целей обучения. Три конструкции описаны ниже:

Live — одна из трех конструкций, представляющих людей, работающих с операционной системой соответствующих дисциплин. Примерами операционной системы могут быть танк, военно-морской корабль, самолет или даже развернутый хирургический госпиталь. Три компонента Live Construct следуют

• Live vs. Live: Традиционное обучение Live vs. Live является компонентом Live Construct и происходит, когда оперативные системы Live взаимодействуют друг с другом, увеличивая сложность сценария (кстати, именно так и происходит реальный бой, что делает этот компонент наиболее захватывающей формой боевой подготовки, доступной сегодня).
• LC: Live, Constructive — это компонент Live Construct, посредством которого CGF внедряются в операционные системы Live в двунаправленной, интегрированной, безопасной, динамически адаптируемой сети для увеличения сложности сценария.
• LVC: Live, Virtual and Constructive (LVC) — компонент Live Construct, посредством которого виртуальные сущности и CGF внедряются в живые операционные системы в интегрированной, безопасной, динамически адаптируемой сети для увеличения сложности сценария.

Simulator Construct представляет собой комбинацию Virtual и Constructive (VC) и состоит из людей, управляющих симулированными устройствами вместо реальных операционных систем. Simulator Construct состоит из трех компонентов:

• Локально объединенный в сеть набор идентичных симуляторов, типичных для данной среды (автономные симуляторы)
• Сетевой набор разрозненных симуляторов (распределенные операции миссии (DMO))
• Локально замкнутый сетевой анклав из нескольких устройств-симуляторов для поддержки высококлассного тестирования, тактики и расширенного обучения (HET3)

Является ли третья конструкция, отличная от Live или Simulator, в которой обучение осуществляется с помощью многих компонентов (не всеобъемлющих)?

• Компьютерное обучение
• Самостоятельное изучение
• Платформа проинструктировала ученых

Используя приведенные выше определения, в следующей таблице графически показано, как термины соотносятся в контексте обучения или эксплуатационных испытаний CAF:

Используя рисунок выше в качестве руководства, становится ясно, что активность LVC — это использование виртуальной и конструктивной сред для повышения сложности сценария для среды Live — и ничего более. Система LVC должна иметь двунаправленную, адаптивную, специальную и безопасную систему связи между средой Live и средой VC. Самое главное, что LVC, используемое как глагол, представляет собой интегрированное взаимодействие трех сред с постоянно присутствующей средой Live. Например, событие Simulator Construct VC должно называться как-то иначе, чем LVC (например, Distributed Mission Operations (DMO)). При отсутствии среды Live LVC и LC не существуют, что делает использование термина LVC совершенно неуместным в качестве дескриптора.

Поскольку LVC Enterprise относится к программе обучения, направления усилий LVC справедливо определяются как «совместные усилия OSD, HAF, MAJCOM, Joint и Coalition в направлении технологически обоснованного и финансово ответственного пути обучения для обеспечения боевой готовности». «Направления усилий» в этом случае не будут включать программы и разработки Simulator Construct, а будут ограничены Construct, который включает LVC Enterprise. Другой распространенный термин, «Doing LVC», будет тогда подразумевать «обучение готовности, проводимое с использованием интеграции виртуальных и конструктивных активов для дополнения сценариев реальной операционной системы и результатов выполнения задач миссии». Аналогичным образом, LVC-Operational Training (в контексте обучения истребителей CAF) или «LVC-OT» являются инструментами и усилиями, необходимыми для интеграции реальных, виртуальных и конструктивных систем миссии, когда это необходимо, для адаптации надежных и экономически эффективных методов оперативной подготовки и/или тестирования.

Чтобы обеспечить ясность обсуждений и исключить недопонимание, при обсуждении в контексте LVC следует использовать только термины из этого документа для описания сред, конструкций и компонентов. Такие слова, как «синтетический» и «цифровой», следует заменить на «конструктивный» или «виртуальный». Кроме того, системы встроенного обучения (ET), определяемые как локализованная или автономная система Live/Constructive (например, на F-22 или F-35), не следует путать с системами LVC или называть их таковыми.

До 1990 года сфера моделирования и моделирования была отмечена фрагментацией и ограниченной координацией между видами деятельности в ключевых сообществах. Признавая эти недостатки, Конгресс поручил Министерству обороны (DoD) «... создать совместный программный офис на уровне Управления министра обороны (OSD) для моделирования с целью координации политики моделирования, установления стандартов и протоколов взаимодействия, содействия моделированию в военных департаментах и ​​установления руководящих принципов и целей для координации [sic] моделирования, военных игр и обучения». (см. Отчет Комитета по авторизации Сената, FY91, законопроект об ассигнованиях DoD, SR101-521, стр. 154–155, 11 октября 1990 г.) В соответствии с этим направлением было создано Управление моделирования и моделирования обороны (DMSO), и вскоре после этого многие компоненты DoD назначили организации и/или контактные лица для содействия координации деятельности M&S внутри и между своими сообществами. На протяжении более десятилетия конечной целью DoD в M&S является создание LVC-IA для быстрой сборки моделей и симуляций, которые создают операционно действительную среду LVC для обучения, разработки доктрины и тактики, формулирования оперативных планов и оценки боевых ситуаций. Общее использование этих сред LVC будет способствовать более тесному взаимодействию между операциями и сообществами по приобретению. Эти среды M&S будут построены из составных компонентов, взаимодействующих через интегрированную архитектуру. Надежные возможности M&S позволяют DOD эффективно выполнять оперативные и вспомогательные задачи в рамках разнообразных видов деятельности военных служб, боевых командований и агентств. ^{[5] [6]}

Количество доступных архитектур со временем увеличилось. Тенденции M&S показывают, что как только вокруг архитектуры сформируется сообщество пользователей, эта архитектура, скорее всего, будет использоваться независимо от новых архитектурных разработок. Тенденции M&S также показывают, что лишь немногие архитектуры, если таковые вообще будут, будут выведены из эксплуатации по мере появления новых. Когда создается новая архитектура для замены одной или нескольких из существующих наборов, вероятным результатом будет добавление еще одной архитектуры к доступному набору. По мере того, как количество событий смешанной архитектуры со временем увеличивается, проблема межархитектурной коммуникации также возрастает. ^[7]

Компания M&S достигла значительного прогресса в предоставлении пользователям возможности связывать критически важные ресурсы посредством распределенных архитектур.

В середине 1980-х годов SIMNET стала первой успешной реализацией крупномасштабной, работающей в режиме реального времени, сети симуляторов с человеком в контуре для командной подготовки и репетиций миссий в военных операциях. Самым ранним успехом, достигнутым в рамках программы SIMNET, стала демонстрация того, что географически распределенные системы симуляции могут поддерживать распределенное обучение, взаимодействуя друг с другом через сетевые соединения. ^[8]

Протокол моделирования на совокупном уровне (ALSP) расширил преимущества распределенного моделирования для сообщества по обучению на уровне сил, чтобы различные моделирования на совокупном уровне могли сотрудничать для предоставления опыта на уровне театра военных действий для обучения боевого состава. ALSP поддерживал развивающуюся «конфедерацию моделей» с 1992 года, состоящую из набора инфраструктурного программного обеспечения и протоколов как для межмодельной коммуникации через общий интерфейс, так и для продвижения по времени с использованием консервативного алгоритма на основе Чанди-Мисры. ^[9]

Примерно в то же время протокол SIMNET развился и превратился в стандарт распределенного интерактивного моделирования (DIS). DIS позволял большему количеству типов моделирования взаимодействовать в распределенных событиях, но в первую очередь был ориентирован на сообщество обучения на уровне платформы. DIS предоставил открытый стандарт сетевого протокола для связывания симуляций военных игр на уровне платформы в реальном времени. ^[10]

В середине 1990-х годов Управление моделирования и симуляции обороны (DMSO) спонсировало инициативу архитектуры высокого уровня (HLA). Разработанная для поддержки и замены DIS и ALSP, исследовательская работа была начата с целью создания прототипа инфраструктуры, способной поддерживать эти два разнородных приложения. Цель состояла в том, чтобы объединить лучшие особенности DIS и ALSP в единую архитектуру, которая также могла бы поддерживать использование в сообществах анализа и сбора данных, продолжая при этом поддерживать приложения для обучения.

Сообщество по тестированию DoD начало разработку альтернативных архитектур, основанных на их восприятии того, что HLA давала неприемлемую производительность и включала ограничения надежности. Сообщество по тестированию в реальном времени начало разработку архитектуры обеспечения тестирования и обучения (TENA) для предоставления малозадерживаемого, высокопроизводительного сервиса в жестком реальном времени приложения интеграции живых активов в условиях тестового полигона. TENA, через свою общую инфраструктуру, включая TENA Middleware и другие дополнительные компоненты архитектуры, такие как TENA Repository, Logical Range Archive и другие утилиты и инструменты TENA, обеспечивает архитектуру и реализацию программного обеспечения и возможности, необходимые для быстрого и экономичного обеспечения взаимозаменяемости между системами полигонов, объектами и симуляциями. ^{[11] [12] [13]}

Аналогичным образом армия США начала разработку архитектуры единой учебной аппаратуры (CTIA) для объединения большого количества реальных активов, требующих относительно узко ограниченного набора данных для целей предоставления обзоров действий (AAR) на армейских полигонах в поддержку крупномасштабных учений. ^[14]

Другие усилия, которые усложняют пространство архитектуры LVC, включают универсальные пакеты программного обеспечения для взаимозаменяемости, такие как OSAMS ^[15] или CONDOR ^[16], разработанные и распространяемые коммерческими поставщиками.

По состоянию на 2010 год все архитектуры DoD остаются в эксплуатации, за исключением SIMNET. Из оставшихся архитектур: CTIA, DIS, HLA, ALSP и TENA, некоторые находятся на ранней стадии и все больше используются (например, CTIA, TENA), в то время как другие столкнулись с сокращением пользовательской базы (например, ALSP). Каждая из архитектур обеспечивает приемлемый уровень возможностей в областях, где они были приняты. Однако федерации на основе DIS, HLA, TENA и CTIA по своей сути несовместимы друг с другом. когда моделирование основано на разных архитектурах, необходимо предпринять дополнительные шаги для обеспечения эффективной связи между всеми приложениями. Эти дополнительные шаги, обычно включающие установку шлюзов или мостов между различными архитектурами, могут привести к повышению риска, сложности, стоимости, уровня усилий и времени подготовки. Дополнительные проблемы выходят за рамки реализации отдельных событий моделирования. В качестве одного примера можно привести ограниченную возможность повторного использования вспомогательных моделей, персонала (экспертизы) и приложений в разных протоколах. Ограниченная внутренняя совместимость между различными протоколами создает существенный и ненужный барьер для интеграции живых, виртуальных и конструктивных симуляций.

Текущее состояние взаимодействия LVC является хрупким и подвержено нескольким повторяющимся проблемам, которые необходимо решать (часто заново) всякий раз, когда живые, виртуальные или конструктивные системы моделирования должны быть компонентами в событии моделирования со смешанной архитектурой. Некоторые из сопутствующих проблем возникают из-за ограничений возможностей системы моделирования и других несовместимостей между системами. Другие типы проблем возникают из-за общей неспособности предоставить структуру, которая достигает более полной семантической совместимости между разнородными системами. ^[17] Взаимодействие, интеграция и компонуемость были определены как наиболее технически сложные аспекты LVC-IA по крайней мере с 1996 года. Исследование эффективности моделирования и симуляции в процессе приобретения систем оружия ^[18] также выявило культурные и управленческие проблемы. По определению LVC-IA является социально-технической системой , технической системой, которая напрямую взаимодействует с людьми. В следующей таблице указаны проблемы 1996 года, связанные с техническими, культурными и управленческими аспектами. Кроме того, также включены проблемы и пробелы, обнаруженные в исследовании 2009 года. ^[19] Таблица показывает, что между проблемами 1996 года и проблемами 2009 года существует небольшая разница.

Виртуальная или конструктивная модель обычно фокусируется на точности или достоверности представляемого элемента. Живая симуляция по определению представляет наивысшую достоверность, поскольку она является реальностью. Но симуляция быстро становится сложнее, когда она создается из различных живых, виртуальных и конструктивных элементов или наборов симуляций с различными сетевыми протоколами, где каждая симуляция состоит из набора живых, виртуальных и конструктивных элементов. Симуляции LVC являются социально-техническими системами из-за взаимодействия между людьми и технологиями в симуляции. Пользователи представляют заинтересованные стороны из всех сообществ по приобретению, анализу, тестированию, обучению, планированию и экспериментированию. M&S происходит на протяжении всего жизненного цикла системы разработки интеграции совместных возможностей (JCID). См. рисунок «M&S в процессе JCID». LVC-IA также считается сверхбольшой системой (ULS) из-за использования широким кругом заинтересованных сторон с противоречивыми потребностями и непрерывно развивающейся конструкции из разнородных частей. ^[20] По определению, люди являются не просто пользователями, а элементами симуляции LVC.

В ходе разработки различных сред LVC-IA были предприняты попытки понять основополагающие элементы интеграции, компонуемости и интероперабельности. По состоянию на 2010 год наше понимание этих трех элементов все еще развивается, так же как и разработка программного обеспечения продолжает развиваться. Рассмотрим архитектуру программного обеспечения; как концепция она была впервые определена в исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х годов. Область архитектуры программного обеспечения была принята ISO только в 2007 году как ISO/IEC 42010:2007. Интеграция обычно описывается с использованием методов архитектурных и программных шаблонов. Функциональные элементы интеграции можно понять благодаря универсальности шаблонов интеграции, например, посредничество (внутрисистемная коммуникация) и федерация (межсистемная коммуникация); шаблоны процесса, синхронизации данных и параллелизма .

LVC-IA зависит от атрибутов Interoperability и Composability, не только технических аспектов, но также социальных или культурных аспектов. Существуют социально-технические проблемы, а также проблемы системы ULS, связанные с этими особенностями. Примером культурного аспекта является проблема валидности композиции. В ULS возможность контролировать все интерфейсы для обеспечения валидной композиции чрезвычайно сложна. Парадигмы VV&A бросают вызов определению уровня приемлемой валидности.

Изучение взаимодействия касается методологий взаимодействия различных систем, распределенных по сетевой системе. Андреас Толк представил Уровни концептуальной модели взаимодействия (LCIM), которая определила семь уровней взаимодействия между участвующими системами как метод описания технического взаимодействия и сложности взаимодействия. ^[21]

Теория моделирования и имитации Бернарда Зейглера распространяется на три основных уровня взаимодействия:

• Прагматичный
• Семантический
• Синтаксический

Прагматический уровень фокусируется на интерпретации сообщений получателем в контексте применения относительно намерения отправителя. Семантический уровень касается определений и атрибутов терминов и того, как они объединяются для предоставления общего смысла сообщениям. Синтаксический уровень фокусируется на структуре сообщений и соблюдении правил, управляющих этой структурой. Концепция лингвистической совместимости поддерживает одновременную среду тестирования на нескольких уровнях.

LCIM связывает нижние уровни с проблемами взаимодействия моделирования, в то время как верхние уровни относятся к проблемам повторного использования и композиции моделей. Они приходят к выводу, что «системы моделирования основаны на моделях и их предположениях и ограничениях. Если объединить две системы моделирования, эти предположения и ограничения должны быть соответствующим образом согласованы для обеспечения значимых результатов». Это говорит о том, что уровни взаимодействия, которые были выявлены в области M&S, могут служить руководящими принципами для обсуждения обмена информацией в целом.

Архитектура Зейглера предоставляет язык описания архитектуры или концептуальную модель для обсуждения M&S. LCIM предоставляет концептуальную модель как средство для обсуждения интеграции, взаимодействия и компоновки. Три лингвистических элемента связывают LCIM с концептуальной моделью Зейглера. Архитектурная и структурная сложность являются областью исследований в теории систем для измерения связности и связи и основываются на метриках, обычно используемых в проектах по разработке программного обеспечения. Зейглер, Ким и Прехофер представляют теорию моделирования и имитации, которая предоставляет концептуальную структуру и связанный вычислительный подход к методологическим проблемам в M&S. Структура предоставляет набор сущностей и отношений между сущностями, которые, по сути, представляют онтологию области M&S. ^[22]

Петти и Вайзель ^[23] сформулировали текущее рабочее определение: «Композируемость — это способность выбирать и собирать компоненты моделирования в различных комбинациях в системы моделирования для удовлетворения конкретных требований пользователя». Требуется как техническое, так и пользовательское взаимодействие, указывающее на то, что задействована социотехническая система. Возможность для пользователя получать доступ к данным или моделям является важным фактором при рассмотрении метрик композируемости. Если у пользователя нет видимости в репозитории моделей, агрегация моделей становится проблематичной.

В работе «Улучшение компоновки моделей и моделирования Министерства обороны» факторы, связанные с возможностью обеспечения компоновки, следующие:

• Сложность моделируемой системы. Размер (сложность) среды M&S.
• Сложность цели для контекста, в котором будет использоваться составной M&S. Гибкость исследования, расширяемость.
• Сила основополагающей науки и технологий, включая стандарты.
• Человеческие факторы, такие как качество управления, наличие общих интересов, а также навыки и знания рабочей силы. ^[24]

Толк ^[25] представил альтернативный взгляд на компоновку, сосредоточившись больше на необходимости концептуального согласования:

Сообщество M&S хорошо понимает интероперабельность как способность обмениваться информацией и использовать данные, которыми обмениваются в принимающей системе. Интероперабельность может быть встроена в систему или услугу после определения и внедрения. ...

Композируемость отличается от интероперабельности. Композируемость — это последовательное представление истины во всех участвующих системах. Она расширяет идеи интероперабельности, добавляя прагматический уровень для охвата того, что происходит в принимающей системе на основе полученной информации. В отличие от интероперабельности, композируемость не может быть встроена в систему постфактум. Композируемость часто требует значительных изменений в моделировании.

Другими словами: Концепты с собственными свойствами, если они моделируются в более чем одной участвующей системе, должны представлять одну и ту же истину. Не допускается, чтобы компонуемые системы получали разные ответы на один и тот же вопрос в обеих системах. Требование последовательного представления истины заменяет требование осмысленного использования полученной информации, известной из взаимодействия.

Page et al. ^[26] предлагают определить интегрируемость, конкурирующую с физическими/техническими сферами соединений между системами, которые включают в себя аппаратное и встроенное ПО, протоколы, сети и т. д., интероперабельность, конкурирующую с программным обеспечением и деталями реализации интеропераций; это включает обмен элементами данных через интерфейсы, использование промежуточного программного обеспечения, сопоставление с общими моделями обмена информацией и т. д., и компонуемость, конкурирующую с выравниванием проблем на уровне моделирования. Как отмечено, среди прочего, Толком ^[27], успешное взаимодействие решений компонентов LVC требует интегрируемости инфраструктур, интероперабельности систем и компонуемости моделей . Архитектуры LVC должны целостно рассматривать все три аспекта в хорошо согласованных системных подходах.

Чтобы получить максимальный эффект от своих инвестиций, DoD необходимо управлять своими программами M&S, используя подход корпоративного типа. Это включает в себя как выявление пробелов в возможностях M&S, которые являются общими для всего предприятия, так и предоставление начальных средств для финансирования проектов, которые имеют широко применимые выплаты, а также проведение инвестиций M&S по всему Департаменту систематическим и прозрачным образом. В частности, «Управленческие процессы для моделей, симуляций и данных, которые… Содействуют экономически эффективной и действенной разработке систем и возможностей M&S…», такие как указаны в заявлении о видении, требуют комплексных инвестиционных стратегий и процессов передовой практики Департамента M&S. Управление инвестициями M&S требует показателей, как для количественной оценки объема потенциальных инвестиций, так и для выявления и понимания полного спектра выгод, получаемых от этих инвестиций. В настоящее время нет единого руководства для такой практики. ^[28]

Расходы на разработку и использование, связанные с LVC, можно суммировать следующим образом: ^{[29] [30]}

• В прямом эфире — относительно высокая стоимость, поскольку требует больших затрат человеческих ресурсов и материальных средств и не отличается особой повторяемостью.
• Виртуальный — относительно средняя стоимость, поскольку требует меньших человеческих ресурсов / материалов , возможно повторное использование, а повторяемость средняя.
• Конструктивный — относительно низкая стоимость, поскольку требует наименьших затрат человеческих ресурсов / материалов , возможна значительная повторная эксплуатация и высокая повторяемость.

Напротив, точность M&S самая высокая в режиме Live, ниже в режиме Virtual и самая низкая в режиме Constructive. Таким образом, политика DoD представляет собой смешанное использование LVC в течение жизненного цикла Military Acquisition , также известное как LVC Continuum . На рисунке LVC Continuum справа процесс JCIDS связан с относительным использованием LVC в течение жизненного цикла Military Acquisition .

• Получение данных на основе моделирования