Live, virtuellt och konstruktivt

Live, Virtual, & Constructive ( LVC ) simulering är en allmänt använd taxonomi för klassificering av modellering och simulering ( M&S). Att kategorisera en simulering som en levande, virtuell eller konstruktiv miljö är dock problematiskt eftersom det inte finns någon tydlig uppdelning mellan dessa kategorier. Graden av mänskligt deltagande i en simulering är oändligt variabel, liksom graden av utrustningsrealism. Kategoriseringen av simuleringar saknar också en kategori för simulerade personer som arbetar med riktig utrustning.

Kategorier

LVC-kategorierna enligt definitionen av USA:s försvarsdepartement i modellerings- och simuleringsordlistan enligt följande:

  • Live - En simulering som involverar riktiga människor som använder riktiga system. Militära träningsevenemang med riktig utrustning är livesimuleringar. De anses vara simuleringar eftersom de inte utförs mot en levande fiende.
  • Virtual - En simulering som involverar riktiga människor som använder simulerade system. Virtuella simuleringar injicerar en Human-in-the-Loop i en central roll genom att utöva motorisk kontrollfärdighet (t.ex. flygande jet- eller stridsvagnssimulator), beslutsfattande färdigheter (t.ex. att satsa eldledningsresurser) eller kommunikationsförmåga (t.ex. som medlemmar i ett C4I -team).
  • Constructive - En simulering som involverar simulerade människor som använder simulerade system. Riktiga människor stimulerar (gör insatser till) sådana simuleringar, men är inte involverade i att bestämma resultaten. En konstruktiv simulering är ett datorprogram. Till exempel kan en militär användare mata in data som instruerar en enhet att förflytta sig och att angripa ett fiendemål. Den konstruktiva simuleringen avgör rörelsehastigheten, effekten av ingreppet med fienden och eventuella stridsskador som kan uppstå. Dessa termer bör inte förväxlas med specifika konstruktiva modeller som Computer Generated Forces (CGF), en generisk term som används för att referera till datorrepresentationer av krafter i simuleringar som försöker modellera mänskligt beteende. CGF är bara ett exempel på en modell som används i en konstruktiv miljö. Det finns många typer av konstruktiva modeller som involverar simulerade människor som använder simulerade system.

Andra associerade termer är följande:

Andra definitioner som används i LVC-diskussioner (Websters ordbok)

  1. Företag: ett projekt eller företag som är särskilt svårt, komplicerat eller riskabelt
    • A: en enhet för ekonomisk organisation eller verksamhet; särskilt: en företagsorganisation
    • B: en systematisk målmedveten verksamhet
  2. Miljö: Sammansättningen av omgivande saker, förhållanden eller influenser; miljö
  3. Konstruera: Att tillverka eller forma genom att kombinera eller arrangera komponenter
  4. Komponent: En av delarna av något

Nuvarande och framväxande teknologi för att möjliggöra äkta LVC-teknik för Combat Air Forces ("CAF") utbildning kräver att standardiserade definitioner av CAF LVC-händelser diskuteras och utvecklas. Ordbokstermerna som används ovan ger en solid grund för förståelse av den grundläggande strukturen för LVC-ämnet som tillämpas universellt på DoD-aktiviteter. Termerna och användningsfallen som beskrivs nedan är en vägledning för doktriner som använder dessa termer för att eliminera alla missförstånd. Följande stycke använder dessa termer för att layouta den globala vyn, och kommer att förklaras i detalj i resten av dokumentet. Kortfattat:

Träning och operativa test genomförs genom den kombinerade användningen av tre separata konstruktioner (Live, Simulator och Acillary) som i sin tur består av flera som gör det möjligt för komponenter att förbereda, testa och/eller träna krigskämpar i sina respektive discipliner. LVC Enterprise, en komponent i Live-konstruktionen, är helheten av personal, hårdvara och mjukvara som gör det möjligt för krigskämpar att kombinera tre historiskt olika miljöer (Live, Virtual och Constructive) för att förbättra prestanda i sin stridsroll.

Centralt för en funktionellt korrekt förståelse av stycket ovan är en praktisk kunskap om miljödefinitionerna, som tillhandahålls nedan för tydlighetens skull:

  • Livemiljö (L)*: Warfighters som använder sina respektive discipliners operativa system i en verklig applikation
  • Virtual Environment (V)*: Warfighters som arbetar med simulatorer eller tränare i fält
  • Constructive Environment (C)*: Computer Generated Forces (CGF) som används för att öka och tvinga multiplicera Live och/eller Virtual scenarioutveckling

Miljöerna (L, V, & C) i sig själva är i allmänhet väl förstådda och gäller universellt för en mängd olika discipliner såsom det medicinska området, brottsbekämpande eller operativa militära tillämpningar. Med det medicinska området som exempel kan Live Environment vara en läkare som utför HLR på en mänsklig patient i en kritisk verklig situation. I samma sammanhang skulle den virtuella miljön inkludera en läkare som utövar HLR på en träningsdocka, och den konstruktiva miljön är programvaran i träningsdockan som driver dess beteende. I ett andra exempel, överväg utbildning av stridspilot eller operativa tester. Live-miljön är piloten som flyger stridsflygplanet. Den virtuella miljön skulle omfatta samma pilot som flyger en simulator. Den konstruktiva miljön inkluderar nätverken, datorgenererade styrkor och vapenservrar, etc. som gör att Live och Virtual miljöer kan anslutas och interagera. Även om det helt klart finns sekundära och högre utbildningsfördelar är det viktigt att förstå att kombinera en eller flera miljöer i syfte att göra Live verkliga prestanda bättre är den enda anledningen till att LVC-konceptet skapades. Men när man hänvisar till specifika aktiviteter eller program som är utformade för att integrera miljöer i hela företaget, skiljer sig användningen och tillämpningen av termer kraftigt över DoD. Därför kräver de ord som specifikt beskriver hur framtida utbildning eller operativa testning kommer att genomföras också standardisering. Detta beskrivs bäst genom att backa från teknisk terminologi och tänka på hur människor faktiskt förbereder sig för sitt specifika stridsansvar. I praktiken förbereder sig människor för sina roller i en av tre konstruktioner: Live (med faktiska stridsverktyg), i en simulator av något slag, eller på andra underordnade sätt (tester, akademiker, datorbaserad träning, etc.). Åtgärder inom var och en av konstruktionerna är ytterligare nedbruten i komponenter som specificerar olika sätt att få jobbet gjort eller uppnå utbildningsmål. De tre konstruktionerna beskrivs nedan:

Live konstruktion

Live är en av tre konstruktioner som representerar människor som driver sina respektive discipliners operativa system. Exempel på operativa system kan bestå av en stridsvagn, ett marinfartyg, ett flygplan eller så småningom till och med ett utplacerat kirurgiskt sjukhus. Tre komponenter i Live Construct följer

  • Live vs. Live: Traditionell Live vs. Live-träning är en komponent i Live Construct och sker när Live-operativsystem interagerar med varandra för att öka scenariets komplexitet (för övrigt är det så den faktiska striden också utförs; vilket gör denna komponent till den mest fullständiga uppslukande form av stridsträning tillgänglig idag)
  • LC: Live, Constructive är en komponent i Live Construct där CGF:er injiceras i Live-operativsystem i ett dubbelriktat, integrerat, säkert, dynamiskt anpassningsbart nätverk för att öka scenariots komplexitet
  • LVC: Live, Virtual and Constructive (LVC) är en komponent i Live Construct där virtuella enheter och CGF:er injiceras i Live-operativsystem i ett integrerat, säkert, dynamiskt anpassningsbart nätverk för att öka scenariets komplexitet

Simulatorkonstruktion

Simulatorkonstruktionen är en kombination av virtuell och konstruktiv (VC) och består av människor som använder simulerade enheter i stället för live-operativsystem. Simulatorkonstruktionen består av tre komponenter:

  • En lokalt nätverksuppsättning identiska simulatorer som är typiska för miljön (fristående simulatorer)
  • En nätverksuppsättning olika simulatorer (Distributed Mission Operations (DMO))
  • En lokalt sluten slinga nätverksansluten enklav av flera simulatorenheter till stöd för avancerad testning, taktik och avancerad träning (HET3)

Tilläggskonstruktion

Är den tredje konstruktionen annan än Live eller Simulator där träning sker via många komponenter (inte all inclusive)

  • Datorbaserad undervisning
  • Självstudie
  • Plattformsinstruerade akademiker

Med användning av definitionerna ovan ger följande tabell en grafisk representation av hur termerna förhåller sig i samband med CAF Training eller Operational Test:

Med hjälp av figuren ovan som en guide är det tydligt att LVC-aktivitet är användningen av de virtuella och konstruktiva miljöerna för att förbättra scenariokomplexiteten för Live-miljön – och inget mer. Ett LVC-system måste ha ett dubbelriktat, anpassningsbart, ad-hoc och säkert kommunikationssystem mellan Live-miljön och VC-miljön. Viktigast är att LVC som används som verb är en integrerad interaktion mellan de tre miljöerna med Live-miljön alltid närvarande. Till exempel bör en Simulator Construct VC-händelse kallas något annat än LVC (som Distributed Mission Operations (DMO)). I avsaknad av Live-miljön existerar inte LVC och LC, vilket gör användningen av LVC-termen helt olämplig som en deskriptor.

Eftersom LVC Enterprise hänför sig till ett utbildningsprogram, definieras LVC-insatser med rätta som "ett samarbete mellan OSD, HAF, MAJCOM, Joint and Coalition insatser mot en tekniskt sund och skattemässigt ansvarsfull väg för utbildning för att möjliggöra stridsberedskap." "Ansträngningslinjerna", i det här fallet, skulle inte inkludera Simulator Construct-program och utveckling utan skulle vara begränsade till den Construct som inkluderar LVC Enterprise. Den andra vanliga termen, "Doing LVC" skulle då antyda "beredskapsträning som genomförs med användning av en integration av virtuella och konstruktiva tillgångar för att utöka Live-operativsystemscenarier och uppdragsmålresultat." Likaså är LVC-operativ utbildning (i ett CAF-stridsflygträningssammanhang) eller "LVC-OT" de verktyg och ansträngningar som krävs för att integrera live-, virtuella och konstruktiva uppdragssystem, när det behövs, för att skräddarsy robusta och kostnadseffektiva metoder för operativ utbildning och/eller test.

Missbrukade och främmande termer

För att säkerställa klarhet i diskussioner och eliminera missförstånd, när man talar i LVC-sammanhang, bör endast termerna i detta dokument användas för att beskriva miljöer, konstruktioner och komponenter. Ord som "syntetisk" och "digi" bör istället ersättas med "Konstruktiv" eller "Virtuell". Dessutom bör inbyggda träningssystem (ET), definierade som ett lokaliserat eller fristående Live/Constructive-system (som på F-22 eller F-35) inte förväxlas med eller hänvisas till som LVC-system.

Historia

LVC Simulation Architectures Venn Diagram
Användningsfrekvens för simuleringsarkitekturer

Före 1990 präglades M&S-området av fragmentering och begränsad samordning mellan aktiviteter över nyckelsamhällen. Som ett erkännande av dessa brister instruerade kongressen försvarsdepartementet (DoD) att "... inrätta ett kontor för försvarsministerns (OSD)-nivå gemensamt programkontor för simulering för att koordinera simuleringspolicy, för att upprätta interoperabilitetsstandarder och protokoll, för att främja simulering inom de militära avdelningarna och att fastställa riktlinjer och mål för samordning [sic] av simulering, krigsspel och träning." (ref Senate Authorization Committee Report, FY91, DoD Appropriations Bill, SR101-521, s. 154–155, 11 oktober 1990) I enlighet med denna riktning skapades Defense Modeling and Simulation Office (DMSO) och kort därefter många DoD Komponenter utsedda organisationer och/eller kontaktpunkter för att underlätta samordning av M&S-aktiviteter inom och över deras samhällen. I över ett decennium är det slutliga målet för DoD i M&S att skapa en LVC-IA för att snabbt montera modeller och simuleringar, som skapar en operativt giltig LVC- miljö för att träna, utveckla doktrin och taktik, formulera operativa planer och bedöma stridssituationer. En gemensam användning av dessa LVC-miljöer kommer att främja ett närmare samspel mellan verksamheter och förvärvsgemenskaper. Dessa M&S-miljöer kommer att konstrueras av komponerbara komponenter som samverkar genom en integrerad arkitektur. En robust M&S-kapacitet gör det möjligt för DOD att effektivt uppfylla operativa och stödja mål över de olika aktiviteterna inom militärtjänsten, stridande kommandon och byråer.

Antalet tillgängliga arkitekturer har ökat med tiden. M&S-trender indikerar att när en användningsgemenskap väl utvecklas kring en arkitektur, kommer den arkitekturen sannolikt att användas oavsett ny arkitektonisk utveckling. M&S-trender indikerar också att få, om några, arkitekturer kommer att pensioneras när nya kommer online. När en ny arkitektur skapas för att ersätta en eller flera av den befintliga uppsättningen, är det troliga resultatet att ytterligare en arkitektur kommer att läggas till den tillgängliga uppsättningen. När antalet händelser med blandad arkitektur ökar över tiden, ökar också kommunikationsproblemet mellan arkitekturerna.

M&S har gjort betydande framsteg när det gäller att göra det möjligt för användare att länka kritiska resurser genom distribuerade arkitekturer.

I mitten av 1980-talet blev SIMNET den första framgångsrika implementeringen av ett storskaligt, realtids-, man-in-the-loop-simulatornätverk för teamträning och uppdragsrepetition i militära operationer. De tidigaste framgångarna som kom genom SIMNET-programmet var demonstrationen att geografiskt spridda simuleringssystem kunde stödja distribuerad träning genom att interagera med varandra över nätverksanslutningar.

Aggregate Level Simulation Protocol (ALSP) utökade fördelarna med distribuerad simulering till träningsgemenskapen på kraftnivå så att olika simuleringar på aggregatnivå kunde samarbeta för att tillhandahålla upplevelser på teaternivå för träning av stridspersonal. ALSP har stött en utvecklande "konfederation av modeller" sedan 1992, bestående av en samling av infrastrukturprogramvara och protokoll för både kommunikation mellan modeller genom ett gemensamt gränssnitt och tidsförskjutning med en konservativ Chandy-Misra-baserad algoritm.

Vid ungefär samma tid utvecklades SIMNET-protokollet och mognade till DIS-standarden ( Distributed Interactive Simulation) . DIS tillät ett ökat antal simuleringstyper att interagera i distribuerade evenemang, men var främst inriktad på utbildningsgemenskapen på plattformsnivå. DIS tillhandahöll en standard för öppet nätverksprotokoll för att länka realtids wargaming-simuleringar på plattformsnivå.

I mitten av 1990-talet sponsrade Defense Modeling and Simulation Office (DMSO) initiativet High Level Architecture (HLA). Utformad för att stödja och ersätta både DIS och ALSP, påbörjades utredningsarbeten för att prototypa en infrastruktur som kan stödja dessa två olika tillämpningar. Avsikten var att kombinera de bästa egenskaperna hos DIS och ALSP till en enda arkitektur som också kunde stödja användningar i analys- och förvärvsgemenskaper samtidigt som man fortsätter att stödja utbildningsapplikationer.

DoD-testgemenskapen startade utvecklingen av alternativa arkitekturer baserat på deras uppfattning att HLA gav oacceptabel prestanda och inkluderade tillförlitlighetsbegränsningar. Realtidstestområdesgemenskapen startade utvecklingen av Test and Training Enabling Architecture (TENA) för att tillhandahålla högpresterande tjänster med låg latens i den hårda realtidsapplikationen för att integrera aktiva tillgångar i testområdet. TENA tillhandahåller, genom sin gemensamma infrastruktur, inklusive TENA Middleware och andra kompletterande arkitekturkomponenter, såsom TENA Repository, Logical Range Archive och andra TENA-verktyg och verktyg, den arkitektur och mjukvaruimplementering och kapacitet som krävs för att snabbt och ekonomiskt möjliggöra utbytbarhet mellan räckviddssystem, faciliteter och simuleringar.

På liknande sätt startade den amerikanska armén utvecklingen av Common Training Instrumentation Architecture (CTIA) för att länka ett stort antal levande tillgångar som kräver en relativt snävt avgränsad uppsättning data för att tillhandahålla After Action Reviews (AARs) på arméns utbildningsområden i stödet av storskaliga övningar.

Andra ansträngningar som gör LVC-arkitekturen mer komplex inkluderar programvarupaket för universella utbytbarhet såsom OSAMS eller CONDOR utvecklade och distribuerade av kommersiella leverantörer.

Från och med 2010 förblir alla DoD-arkitekturer i drift med undantag för SIMNET. Av de återstående arkitekturerna: CTIA, DIS, HLA, ALSP och TENA, är vissa i tidig och växande användning (t.ex. CTIA, TENA) medan andra har sett en minskning av användarbasen (t.ex. ALSP). Var och en av arkitekturerna ger en acceptabel nivå av förmåga inom de områden där de har antagits. DIS, HLA, TENA och CTIA-baserade federationer är dock inte i sig interoperabla med varandra. när simuleringar bygger på olika arkitekturer måste ytterligare åtgärder vidtas för att säkerställa effektiv kommunikation mellan alla applikationer. Dessa ytterligare steg, som vanligtvis involverar mellanliggande gateways eller broar mellan de olika arkitekturerna, kan introducera ökad risk, komplexitet, kostnad, ansträngningsnivå och förberedelsetid. Ytterligare problem sträcker sig bortom implementeringen av enskilda simuleringshändelser. Som ett enda exempel är möjligheten att återanvända stödmodeller, personal (expertis) och applikationer över de olika protokollen begränsad. Den begränsade inneboende interoperabiliteten mellan de olika protokollen introducerar en betydande och onödig barriär för integrationen av live, virtuella och konstruktiva simuleringar.

Utmaningar

Den nuvarande statusen för LVC-interoperabilitet är bräcklig och föremål för flera återkommande problem som måste lösas (ofta på nytt) närhelst live, virtuella eller konstruktiva simuleringssystem ska vara komponenter i en simuleringshändelse med blandad arkitektur. Några av de medföljande problemen härrör från begränsningar av simuleringssystemets förmåga och andra system-till-system-inkompatibiliteter. Andra typer av problem uppstår från det allmänna misslyckandet med att tillhandahålla ett ramverk som uppnår en mer fullständig interoperabilitet på semantisk nivå mellan olika system. Interoperabilitet, integration och kompositionsbarhet har identifierats som de mest tekniska utmanande aspekterna av en LVC-IA sedan åtminstone 1996. Studien om effektiviteten av modellering och simulering i vapensystemförvärvsprocessen identifierade också kulturella och ledningsmässiga utmaningar. Per definition är en LVC-IA ett socialtekniskt system , ett tekniskt system som interagerar direkt med människor. Följande tabell identifierar 1996 års utmaningar förknippade med tekniska, kulturella och administrativa aspekter. Dessutom ingår även utmaningarna eller luckorna i en studie från 2009. Tabellen visar att det är liten skillnad mellan utmaningarna 1996 och utmaningarna 2009.

Typ 1996 Utmaningar 2009 års utmaningar
Teknisk
  • Interoperabilitet
  • Data Beskrivning Tillgänglighet
  • Datasäkerhet och känslighet
  • Fysikbaserad M&S
  • Begränsningar för hårdvara och mjukvara
  • Variabel upplösning
  • Interoperabilitet
  • Data Discovery
  • säkerhet
  • Representativa, komponerbara och validerade modeller
  • Felövervakning och persistens
  • Filtre för trohet, skala och upplösning
Kulturell
  • Förvärvsprocessen
  • Incitament för M&S-användning
  • M&S arbetsstyrka (utbildning och tillgång)
  • Godkännande av M&S
  • Processverktyg
  • Praxisgemenskaper
  • Arbetskraftsutbildning och samarbete
  • Infrastruktur
Ledarskap
  • Office of Secretary Defense Guidance
  • Ägande av data och modeller
  • VV&A
  • Finansieringsprocess
  • Användning av systemmodell
  • Styrning, standardpolicyer
  • Data & Modellförmedling
  • VV&A
  • Konsekvent finansiering
  • Effektiv användning och bästa praxis

Tillvägagångssätt till en lösning

Zieglers arkitektur för modellering och simulering
M&S i JCID-processen

En virtuell eller konstruktiv modell fokuserar vanligtvis på troheten eller noggrannheten hos det element som representeras. En livesimulering representerar per definition den högsta troheten, eftersom den är verklighet. Men en simulering blir snabbt svårare när den skapas från olika levande, virtuella och konstruktiva element, eller uppsättningar av simuleringar med olika nätverksprotokoll, där varje simulering består av en uppsättning levande, virtuella och konstruktiva element. LVC-simuleringarna är socialtekniska system på grund av interaktionen mellan människor och teknik i simuleringen. Användarna representerar intressenter från hela förvärvs-, analys-, test-, utbildnings-, planering- och experimentgemenskaperna. M&S förekommer under hela för Joint Capabilities Integration Development System ( JCID). Se bilden "M&S i JCID-processen". En LVC-IA anses också vara ett ULS-system (Ultra Large Scale) på grund av användningen av en mängd olika intressenter med motstridiga behov och den ständigt utvecklade konstruktionen från heterogena delar. Per definition är människor inte bara användare utan delar av en LVC-simulering.

Under utvecklingen av olika LVC-IA-miljöer uppstod försök att förstå de grundläggande delarna av integration, komponerbarhet och interoperabilitet. Från och med 2010 utvecklas vår förståelse av dessa tre element fortfarande, precis som mjukvaruutvecklingen fortsätter att utvecklas. Tänk på mjukvaruarkitektur; som ett koncept identifierades det först i Edsger Dijkstras forskningsarbete 1968 och David Parnas i början av 1970-talet. Området mjukvaruarkitektur antogs först 2007 av ISO som ISO/IEC 42010:2007. Integration beskrivs rutinmässigt med metoderna för arkitektur- och mjukvarumönster. De funktionella delarna av integration kan förstås på grund av universella integrationsmönster, t.ex. Mediation (intra-kommunikation) och Federation (inter-kommunikation); process, datasynkronisering och samtidighetsmönster .

En LVC-IA är beroende av interoperabilitets- och kompositionsegenskaperna, inte bara de tekniska aspekterna, utan även de sociala eller kulturella aspekterna. Det finns sociotekniska utmaningar, såväl som ULS-systemutmaningar förknippade med dessa funktioner. Ett exempel på en kulturell aspekt är problemet med kompositionsvaliditet. I en ULS är möjligheten att kontrollera alla gränssnitt för att säkerställa en giltig sammansättning extremt svår. VV&A-paradigmen utmanas för att identifiera en nivå av acceptabel validitet.

Interoperabilitet

Studiet av interoperabilitet handlar om metoder för att interoperera olika system fördelade över ett nätverkssystem. Andreas Tolk introducerade Levels of Conceptual Interoperability Model (LCIM) som identifierade sju nivåer av interoperabilitet mellan deltagande system som en metod för att beskriva teknisk interoperabilitet och komplexiteten i interoperationer.

Bernard Zeiglers teori om modellering och simulering sträcker sig över de tre grundläggande nivåerna av interoperabilitet:

  • Pragmatisk
  • Semantisk
  • Syntaktisk

Den pragmatiska nivån fokuserar på mottagarens tolkning av meddelanden i tillämpningssammanhang relativt avsändarens avsikt. Den semantiska nivån avser definitioner och attribut för termer och hur de kombineras för att ge delad mening åt meddelanden. Den syntaktiska nivån fokuserar på en struktur av meddelanden och efterlevnad av reglerna som styr den strukturen. Det språkliga interoperabilitetskonceptet stöder simultan testmiljö på flera nivåer.

LCIM associerar de nedre skikten med problemen med simuleringsinteroperation medan de övre skikten relaterar till problemen med återanvändning och sammansättning av modeller. De drar slutsatsen att "simuleringssystem är baserade på modeller och deras antaganden och begränsningar. Om två simuleringssystem kombineras måste dessa antaganden och begränsningar anpassas för att säkerställa meningsfulla resultat”. Detta tyder på att nivåer av interoperabilitet som har identifierats inom området M&S ​​kan fungera som riktlinjer för diskussion om informationsutbyte i allmänhet.

Zeigler-arkitekturen tillhandahåller ett arkitekturbeskrivningsspråk eller konceptuell modell för att diskutera M&S. LCIM tillhandahåller en konceptuell modell som ett sätt att diskutera integration, interoperabilitet och komponerbarhet. De tre språkliga elementen kopplar LCIM till Zieglers konceptuella modell. Arkitektonisk och strukturell komplexitet är ett forskningsområde inom systemteori för att mäta sammanhållning och koppling och är baserat på de mått som vanligtvis används i programvaruutvecklingsprojekt. Zeigler, Kim och Praehofer presenterar en teori om modellering och simulering som ger ett konceptuellt ramverk och en tillhörande beräkningsmetod för metodologiska problem inom M&S. Ramverket tillhandahåller en uppsättning enheter och relationer mellan enheterna som i praktiken presenterar en ontologi för M&S-domänen.

Kompositerbarhet

Petty och Weisel formulerade den nuvarande arbetsdefinitionen: "Komposerbarhet är förmågan att välja och sätta ihop simuleringskomponenter i olika kombinationer till simuleringssystem för att tillfredsställa specifika användarkrav." Både en teknisk och användarinteraktion krävs som tyder på att ett sociotekniskt system är inblandat. Möjligheten för en användare att få tillgång till data eller åtkomst till modeller är en viktig faktor när man överväger komponerbarhetsmått. Om användaren inte har insyn i ett förråd av modeller blir sammanställningen av modeller problematisk.

När det gäller att förbättra komponerbarheten för försvarsdepartementets modeller och simulering är de faktorer som är förknippade med förmågan att tillhandahålla komponerbarhet följande:

  • Komplexiteten i systemet som modelleras. Storleken (komplexiteten) på M&S-miljön.
  • Målets svårighet för det sammanhang där det sammansatta M&S kommer att användas. Utforskningens flexibilitet, töjbarhet.
  • Styrkan i underliggande vetenskap och teknik, inklusive standarder.
  • Mänskliga hänsyn, såsom kvaliteten på ledningen, att ha en gemensam intressegemenskap och arbetskraftens skicklighet och kunskap.

Tolk introducerade en alternativ syn på kompositionsbarhet, med fokus mer på behovet av konceptuell anpassning:

M&S-gemenskapen förstår interoperabilitet ganska väl som förmågan att utbyta information och att använda data som utbyts i det mottagande systemet. Interoperabilitet kan konstrueras till ett system eller en tjänst efter definition och implementering. ...

Kompositbarhet skiljer sig från interoperabilitet. Sammansättningsbarhet är den konsekventa representationen av sanning i alla deltagande system. Det utökar idéerna om interoperabilitet genom att lägga till den pragmatiska nivån för att täcka vad som händer inom det mottagande systemet baserat på den mottagna informationen. Till skillnad från interoperabilitet kan kompositabilitet inte konstrueras i ett system i efterhand. Kompositerbarhet kräver ofta betydande förändringar av simuleringen.

Med andra ord: Egenskapskoncept, om de är modellerade i mer än ett deltagande system, måste representera samma sanning. Det är inte tillåtet för komponerbara system att få olika svar på samma fråga i båda systemen. Kravet på konsekvent representation av sanning ersätter kravet på meningsfull användning av mottagen information känd från interoperabilitet.

LVC kräver integrerbarhet, interoperabilitet och komponerbarhet

Page et al. föreslå att man definierar integrerbarhet som strider mot de fysiska/tekniska områdena för anslutningar mellan system, vilket inkluderar hårdvara och fast programvara, protokoll, nätverk, etc., interoperabilitet som strider mot programvaran och implementeringsdetaljer för interoperationer; detta inkluderar utbyte av dataelement via gränssnitt, användning av mellanprogram, mappning till vanliga modeller för informationsutbyte, etc., och kompatibilitet som kämpar med anpassningen av frågor på modellnivå. Som fångats, bland annat av Tolk, kräver framgångsrik interoperation av lösningar av LVC-komponenter integrerbarhet av infrastrukturer, interoperabilitet mellan system och komponerbarhet av modeller . LVC Architectures måste holistiskt ta itu med alla tre aspekterna i väl anpassade systemiska tillvägagångssätt.

Ekonomiska drivkrafter

För att få största möjliga effekt av sina investeringar måste DoD hantera sina M&S-program med hjälp av ett företagsliknande tillvägagångssätt. Detta inkluderar både att identifiera luckor i M&S-kapacitet som är vanliga i hela företaget och att tillhandahålla startpengar för att finansiera projekt som har allmänt tillämpliga utdelningar, och att genomföra M&S-investeringar över hela avdelningen på ett sätt som är systematiskt och öppet. I synnerhet, "Styrningsprocesser för modeller, simuleringar och data som ... Underlättar en kostnadseffektiv och effektiv utveckling av M&S-system och kapaciteter ...." sådana som citeras i visionsförklaringen kräver omfattande investeringsstrategier och processer för investeringsstrategier och processer för M&S av avdelningen. M&S-investeringsförvaltning kräver mätvärden, både för att kvantifiera omfattningen av potentiella investeringar och för att identifiera och förstå hela skalan av fördelar som dessa investeringar ger. Det finns för närvarande ingen konsekvent vägledning för sådan praxis.

LVC kontinuum

Utvecklings- och användningskostnaderna förknippade med LVC kan sammanfattas enligt följande:

Däremot är troheten hos M&S högst i Live, lägre i Virtual och lägst i Constructive. Som sådan DoD- policyn en blandad användning av LVC genom Military Acquisition- livscykeln, även känd som LVC Continuum . I LVC Continuum -figuren till höger är JCIDS- processen relaterad till den relativa användningen av LVC genom Military Acquisition- livscykeln.

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=Live,_virtual,_and_constructive&oldid=1115644923 "