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

Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) Эта статья может потребовать очистки, чтобы соответствовать стандартам качества Википедии . Конкретная проблема: необходимо изменить заголовок и подзаголовок. Помогите улучшить эту статью, если можете. ( Октябрь 2014 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) Ведущий раздел этой статьи может неадекватно резюмировать ее содержание . Чтобы соответствовать рекомендациям Википедии по разделу лидов , рассмотрите возможность изменения лида, чтобы обеспечить доступный обзор ключевых моментов статьи таким образом, чтобы он мог стоять сам по себе как краткая версия статьи. ( Март 2015 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

Категории [ править ]

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

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

Другие связанные термины следующие:

• LVC Enterprise - общее предприятие ресурсов, в которых происходит деятельность 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. Описанные ниже термины и варианты использования являются ориентиром для доктрины, в которой эти термины используются для устранения любых недоразумений. В следующем абзаце эти термины используются для компоновки глобального представления, и они будут подробно объяснены в остальной части документа. Коротко:

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

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

• Живая среда (L) *: бойцы, управляющие операционной системой своих дисциплин в реальном приложении.

• Виртуальная среда (V) *: бойцы с боевыми тренажерами или инструкторами.

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

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

Live Construct [ править ]

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 внедряются в операционные системы Live в интегрированной, безопасной, динамически адаптируемой сети для увеличения сложности сценария.

Simulator Construct [ править ]

Вторая конструкция, представляющая людей, управляющих устройствами-симуляторами, вместо операционных систем Live. Конструкция симулятора (комбинация виртуального и конструктивного (VC)) состоит из трех компонентов, которые состоят из

• Локально объединенный в сеть набор идентичных тренажеров, типичных для базы истребителей (автономные тренажеры)
• Сетевой набор разрозненных симуляторов (Distributed Mission Operations (DMO))
• Локально замкнутый сетевой анклав из нескольких симуляторов для поддержки High-End Testing, Tactics и Advanced Training (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. Другой общий термин, «Выполнение LVC», будет означать «обучение готовности, проводимое с использованием интеграции виртуальных и конструктивных ресурсов для дополнения сценариев Live-операционных систем и результатов выполнения задач». Аналогичным образом, LVC-Operational Training (в контексте подготовки бойцов CAF) или LVC-OT - это инструменты и усилия, необходимые для интеграции Live, Virtual и Constructive систем миссий, когда это необходимо,разработать надежные и экономичные методы оперативного обучения и / или тестирования.

Неправильно используемые и посторонние термины [ править ]

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

История [ править ]

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

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

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

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

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

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

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

Сообщество DoD по тестированию начало разработку альтернативных архитектур, основываясь на своем понимании того, что HLA дает неприемлемую производительность и включает ограничения надежности. Сообщество диапазонов тестирования в реальном времени начало разработку архитектуры поддержки тестирования и обучения (TENA) для предоставления высокопроизводительных услуг с малой задержкой в ​​приложении жесткого реального времени по интеграции живых ресурсов в настройках диапазона тестирования. TENA через свою общую инфраструктуру, включая промежуточное ПО TENA и другие дополнительные компоненты архитектуры, такие как репозиторий TENA, архив логических диапазонов и другие утилиты и инструменты 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 зависит от атрибутов взаимодействия и совместимости, а не только от технических аспектов, но также и от социальных или культурных аспектов. Существуют социотехнические проблемы, а также проблемы системы ULS, связанные с этими функциями. Примером культурного аспекта является проблема валидности композиции. В ULS чрезвычайно сложно контролировать все интерфейсы, чтобы гарантировать правильную композицию. Парадигмы VV&A бросают вызов для определения уровня приемлемой достоверности.

Совместимость [ править ]

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

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

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

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

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

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

Возможность компоновки [ править ]

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

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

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

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

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

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

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

LVC требует интегрируемости, взаимодействия и возможности компоновки [ править ]

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

Экономические драйверы [ править ]

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

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

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

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

См. Также [ править ]

• Захват на основе моделирования

Ссылки [ править ]