Samlade nivåsimuleringsprotokoll

Aggregate Level Simulation Protocol (ALSP) är ett protokoll och stödjande programvara som gör det möjligt för simuleringar att samverka med varandra. Ersatt av High Level Architecture (simulering) (HLA) , användes den av den amerikanska militären för att länka analytiska simuleringar och träningssimuleringar.

ALSP består av:

  1. ALSP Infrastructure Software (AIS) som tillhandahåller distribuerad runtime simuleringsstöd och hantering;
  2. Ett återanvändbart ALSP-gränssnitt som består av generiska meddelandeprotokoll för datautbyte; och
  3. Deltagande simuleringar anpassade för användning med ALSP.

Historia

År 1990 anställde Defense Advanced Research Projects Agency (DARPA) . MITER Corporation för att studera tillämpningen av distribuerade interaktiva simuleringsprinciper som används i SIMNET för konstruktiva träningssimuleringar på aggregerad nivå Baserat på prototypinsatser genomfördes ett gemenskapsbaserat experiment 1991 för att utöka SIMNET för att länka samman US Army's Corps Battle Simulation (CBS) och US Air Force's Air Warfare Simulation (AWSIM) . Framgången för prototypen och användarnas erkännande av värdet av denna teknik för utbildningsgemenskapen ledde till utveckling av produktionsmjukvara. Den första ALSP-konfederationen, som tillhandahåller luft-markinteraktioner mellan CBS och AWSIM, stödde tre stora övningar 1992.

1995 hade ALSP övergått till ett program för flera tjänster med simuleringar som representerade US Army (CBS), US Air Force (AWSIM), US Navy (RESA), US Marine Corps (MTWS) , elektronisk krigföring ( JECEWSI ) , logistik ( CSSTSS ) och underrättelsetjänst ( TACSIM ). Programmet hade också övergått från DARPA:s forsknings- och utvecklingsfokus till mainstream-ledning av US Army's Program Executive Office for Simulation, Training and Instrumentation ( PEO STRI )

Bidrag

ALSP utvecklade och demonstrerade nyckelaspekter av distribuerad simulering, av vilka många användes i utvecklingen av HLA.

  • Ingen central nod så att simuleringar kan gå med och avvika från förbundet efter behag
  • Geografisk distribution där simulatorer kan distribueras till olika geografiska platser men ändå utövas i samma simulerade miljö
  • Objektägande så att varje simulering kontrollerar sina egna resurser, skjuter sina egna vapen och fastställer lämplig skada på dess system när den skjuts mot
  • Ett meddelandebaserat protokoll för att distribuera information från en simulering till alla andra simuleringar.
  • Tidshantering så att tiderna för alla simuleringar ser likadana ut för användarna och så att händelsekausaliteten bibehålls – händelser bör ske i samma sekvens i alla simuleringar.
  • Datahantering tillåter alla simuleringar att dela information på ett allmänt förstått sätt även om var och en hade sin egen representation av data. Detta inkluderar flera simuleringar som styr attribut för samma objekt.
  • En arkitektur som tillåter simuleringar att fortsätta använda sina befintliga arkitekturer samtidigt som de deltar i en ALSP-konfederation.

Motivering

1989 var Warrior Preparation Center (WPC) i Einsiedlerhof, Tyskland värd för den datoriserade militärövningen ACE-89. Defense Advanced Research Projects Agency ( DARPA ) använde ACE-89 som en möjlighet att införa teknik genom att finansiera utbyggnaden av Defense Simulation Internet (DSI). Dess paketerade videotelekonferenser förde generalofficerare från NATO-nationer ansikte mot ansikte under en militärövning för första gången; detta mottogs väl. Men programvaran för DSI, distribution av Ground Warfare Simulation (GRWSIM), var mindre framgångsrik. GRWSIM-simuleringen var opålitlig och dess distribuerade databas var inkonsekvent, vilket försämrade övningens effektivitet.

DARPA finansierade utvecklingen av ett distribuerat stridsvagnstränarsystem kallat SIMNET där individuella, datoriserade stridsvagnsbesättningstränare kopplades över lokala nätverk och DSI för att samarbeta i ett enda virtuellt slagfält. Framgången med SIMNET, besvikelsen med ACE-89 och önskan att kombinera befintliga stridssimuleringar fick DARPA att initiera forskning som ledde till ALSP.

Grundläggande grundsatser

DARPA sponsrade utformningen av ett allmänt gränssnitt mellan stora, befintliga stridssimuleringar på samlad nivå. Stridssimuleringar på aggregerad nivå använder Lanchestriska stridsmodeller snarare än individuella fysiska vapenmodeller och används vanligtvis för träning på hög nivå. Trots representationsskillnader tillämpades flera principer för SIMNET på simuleringar på aggregatnivå:

  • Dynamisk konfigurerbarhet. Simuleringar kan gå med och lämna en övning utan begränsningar.
  • Geografisk spridning. Simuleringar kan finnas på olika geografiska platser men ändå träna över samma logiska terräng.
  • Autonoma enheter. Varje simulering kontrollerar sina egna resurser, skjuter sina egna vapen och, när ett av dess föremål träffas, genomför skadebedömning lokalt.
  • Kommunikation genom att skicka meddelanden. En simulering använder ett meddelandeöverförande protokoll för att distribuera information till alla andra simuleringar.

ALSP-utmaningen hade krav utöver SIMNET:s:

  • Simuleringstidshantering. Vanligtvis är simuleringstiden oberoende av väggklockans tid. För att resultaten av en distribuerad simulering ska vara "korrekta" måste tiden vara konsekvent över alla simuleringar.
  • Datahantering. Systemen för intern stat representation skiljer sig mellan befintliga simuleringar, vilket kräver ett gemensamt representationssystem och åtföljande kartläggning och kontrollmekanismer.
  • Arkitektur oberoende. Arkitektoniska egenskaper (implementeringsspråk, användargränssnitt och tidsflödesmekanism) för befintliga simuleringar skilde sig åt. Arkitekturen som antyds av ALSP måste vara diskret för befintliga arkitekturer.

Begreppsram

Ett konceptuellt ramverk är en organiserande struktur av koncept som underlättar utveckling av simuleringsmodeller. Vanliga konceptuella ramverk inkluderar: schemaläggning av händelser, aktivitetsskanning och processinteraktion.

ALSP:s konceptuella ramverk är objektbaserat där en modell är sammansatt av objekt som kännetecknas av attribut till vilka värden tilldelas. Objektklasser är organiserade hierarkiskt på ungefär samma sätt som med objektorienterade programmeringsspråk. ALSP stöder en sammanslutning av simuleringar som koordinerar med en gemensam modell.

För att designa en mekanism som tillåter existerande simuleringar att interagera, är två strategier möjliga: (1) definiera en infrastruktur som översätter mellan representationerna i varje simulering, eller (2) definiera ett gemensamt representationsschema och kräva att alla simuleringar mappas till det schemat.

Den första strategin kräver få störningar av befintliga simuleringar; interaktionen underlättas helt och hållet genom sammankopplingsinfrastrukturen. Denna lösning skalar dock inte bra. På grund av ett underliggande krav på skalbarhet antog ALSP-designen den andra strategin. ALSP föreskriver att varje simulering mappar mellan förbundets representationssystem och dess eget representationssystem. Denna kartläggning representerar ett av de tre sätten på vilka en simulering måste ändras för att delta i en ALSP-konfederation. De återstående ändringarna är:

  • Att inse att simuleringen inte äger alla objekt som den uppfattar.
  • Modifiera simuleringens interna tidsförskjutningsmekanism så att den fungerar i samarbete med andra simuleringar inom förbundet.

I fristående simuleringar kommer objekt till (och försvinner) med simuleringstidens gång och dispositionen av dessa objekt är enbart simuleringens område. När man agerar inom en konfederation är förhållandet simulering-objekt mer komplicerat.

Egenskapen för ägande av simuleringsobjekt är dynamisk, dvs under sin livstid kan ett objekt ägas av mer än en simulering. Faktum är att för vilket värde av simuleringstid som helst kan flera simuleringar äga olika attribut för ett givet objekt. Enligt konvention äger en simulering ett objekt om den äger objektets "identifierande" attribut. Att äga ett objekts attribut innebär att en simulering ansvarar för att beräkna och rapportera förändringar av attributets värde. Objekt som inte ägs av en viss simulering men inom området för uppfattningen för simuleringen kallas spöken. Spöken är lokala kopior av objekt som ägs av andra simuleringar.

När en simulering skapar ett objekt, rapporterar den detta faktum till konfederationen för att låta andra simuleringar skapa spöken. På samma sätt, när en simulering tar bort ett objekt, rapporterar den detta för att möjliggöra spökradering. Närhelst en simulering utför en åtgärd mellan ett av dess objekt och ett spöke, måste simuleringen rapportera detta till konfederationen. I ALSP-språket är detta en interaktion. Dessa grundläggande begrepp utgör grunden för resten av presentationen. Termen konfederationsmodell beskriver objekthierarkin, attribut och interaktioner som stöds av en konfederation.

ALSP Infrastructure Software (AIS)

Det objektbaserade konceptuella ramverket som antagits av ALSP definierar klasser av information som måste distribueras. ALSP Infrastructure Software (AIS) tillhandahåller datadistribution och processkoordinering. Huvudkomponenterna i AIS är ALSP Common Module (ACM) och ALSP Broadcast Emulator (ABE).

ALSP Common Module (ACM)

ALSP Common Module (ACM) tillhandahåller ett gemensamt gränssnitt för alla simuleringar och innehåller den väsentliga funktionaliteten för ALSP. En ACM-instans finns för varje simulering i en konfederation. ACM-tjänster kräver tidshantering och objekthantering; de inkluderar:

  • Koordinera simuleringar som går med i och avgår från en konfederation.
  • Koordinera simulering lokal tid med konfederationstid.
  • Filtrera inkommande meddelanden så att simuleringar endast får meddelanden av intresse.
  • Koordinera ägande av objektattribut och tillåt migrering av ägande.
  • Framtvinga attributägande så att simuleringar endast rapporterar värden för attribut som de äger.

Tidsplanering

Att gå med i och lämna en konfederation är en integrerad del av tidshanteringsprocessen. När en simulering går med i en konfederation skapar alla andra ACM:er i konfederationen ingångsmeddelandeköer för den nya simuleringen. Omvänt, när en simulering lämnar en konfederation raderar de andra ACM:erna ingångsmeddelandeköer för den simuleringen.

ALSP-tidshanteringsfaciliteter stöder diskret händelsesimulering med antingen asynkrona (nästa händelse) eller synkrona (tidsstegade) tidsförskjutningsmekanismer. Mekanismen för att stödja simuleringar av nästa händelse är

  1. En simulering skickar ett meddelande om händelseförfrågan till sin ACM med en tidsparameter som motsvarar simuleringstid T, (tiden för dess nästa lokala händelse).
  2. Om ACM har meddelanden för sin simulering med tidsstämplar äldre än eller samma som T, skickar ACM den äldsta till simuleringen. Om alla meddelanden har tidsstämplar nyare än T, skickar ACM en grant-advance till simuleringen, vilket ger den tillstånd att behandla sin lokala händelse vid tidpunkten T.
  3. Simuleringen skickar alla meddelanden som härrör från händelsen till dess ACM.
  4. Simuleringen upprepas från steg (1).

Mekanismen för att stödja tidsstegssimulering är:

  1. Simuleringen bearbetar alla händelser under ett visst tidsintervall .
  2. Simuleringen skickar en förhandsbegäran till sin ACM för tiden .
  3. ACM skickar alla meddelanden med tidsstämplar på intervallet till simuleringen, följt av en grant-avancemang till T+?T.
  4. Simuleringen skickar alla meddelanden för intervallet till ACM.
  5. Simuleringen upprepas från steg (1).

AIS inkluderar en mekanism för att undvika dödläge som använder nollmeddelanden. Mekanismen kräver att processerna har exploateringsbara lookahead- egenskaper.

Objekthantering

ACM administrerar attributdatabas och filterinformation. Attributdatabasen upprätthåller objekt som är kända för simuleringen, antingen ägda eller ghostade, och attribut för de objekt som simuleringen för närvarande äger. För alla objektklasser kan attribut vara medlemmar av

  • Skapa set. Attribut som minst krävs för att representera ett objekt
  • Ränteuppsättning. Användbar, men inte obligatorisk, information
  • Uppdateringsuppsättning. Objektattributvärden rapporterade av en simulering till konfederationen

Informationsflödet över nätverket kan begränsas ytterligare genom filter. Filtrering ger diskriminering efter (1) objektklass, (2) attributvärde eller intervall och (3) geografisk plats. Filter definierar också de interaktioner som är relevanta för en simulering.

Om (en uppdatering klarar alla filterkriterier) | Om (objektet är känt för simuleringen) | | Skicka nya attributvärden till simulering | Else (objektet är okänt) | | Om (tillräckligt med information finns för att skapa ett spöke) | | | Skicka ett skapa meddelande till simuleringen | | Annars (inte tillräckligt med information är känd) | | | Butiksinformation tillhandahålls | | | Skicka en förfrågan till förbundet för saknad data Else (uppdateringen misslyckas med filterkriterier) | Om (objektet är känt för simuleringen) | | Skicka ett raderingsmeddelande till simuleringen | Annat | | Släng uppdateringsdata

Ägarskaps- och filtreringsinformationen som underhålls av ACM tillhandahåller den information som är nödvändig för att samordna överföringen av attributägande mellan simuleringar.

ALSP Broadcast Emulator (ABE)

En ALSP Broadcast Emulator (ABE) underlättar distributionen av ALSP-information. Den tar emot ett meddelande på en av dess kommunikationsvägar och återsänder meddelandet på alla dess återstående kommunikationsvägar. Detta tillåter konfigurationer där alla ALSP-komponenter är lokala för varandra (på samma dator eller i ett lokalt nätverk). Det tillåter också konfigurationer där uppsättningar av ACM:er kommunicerar med sina egna lokala ABE med inter-ABE kommunikation över wide area networks.

Kommunikationsschema

ALSP-kommunikationsschemat består av (1) en kommunikationsmodell mellan komponenter som definierar transportlagergränssnittet som ansluter ALSP-komponenter, (2) ett lagerprotokoll för simulering-till-simulering-kommunikation, objekthantering och tidshantering, (3) ett meddelandefiltreringsschema för att definiera informationen av intresse för en simulering, och (4) en mekanism för intelligent meddelandedistribution.

Kommunikationsmodell mellan komponenter

AIS använder en beständig kommunikationsmodell för att tillhandahålla kommunikation mellan komponenter. Transportlagergränssnittet som användes för att tillhandahålla kommunikation mellan komponenter dikterades av simuleringskrav och transportlagergränssnitten på AIS-stödjande operativsystem: lokala VMS-plattformar använde delade brevlådor; icke-lokala VMS-plattformar använde antingen Transparent DECnet eller TCP/IP; och UNIX-liknande plattformar använder TCP/IP.

ALSP-protokoll

ALSP-protokollet är baserat på en uppsättning ortogonala frågor som omfattar ALSP:s problemutrymme: simulering-till-simulering-kommunikation, objekthantering och tidshantering. Dessa problem åtgärdas av ett lagerprotokoll som överst har ett simuleringsprotokoll med underliggande simulering/ACM, objekthantering, tidshantering och händelsedistributionsprotokoll.

Simuleringsprotokoll

Simuleringsprotokollet är huvudnivån i ALSP-protokollet. Den består av fyra meddelandetyper:

  • Uppdatering. Objekt i ALSP definieras av ett unikt id-nummer, en klass och en uppsättning attribut associerade med en c1ass. När en simulering ändrar dess objekts tillstånd, skickar den uppdateringsmeddelanden till ACM som tillhandahåller initiala eller ändrade attributvärden. ACM distribuerar sedan informationen via AIS till andra simuleringar som har visat intresse.
  • Samspel. Interaktioner mellan objekt identifieras efter typ. Interaktionstyper beskrivs av parametrar, precis som objekt beskrivs av attribut. När en simuleringsobjekt involverar antingen en annan simuleringsobjekt eller ett geografiskt område, skickar simuleringen ett interaktionsmeddelande till ACM för vidare spridning till andra intresserade simuleringar.
  • Uppdatera begäran. En simulering kan begära en uppdatering av en uppsättning attributvärden för alla objekt eller klasser av objekt genom att skicka ett meddelande om uppdateringsförfrågan till konfederationen.
  • Radera. När en simulering gör att ett av dess objekt upphör att existera, skickar simuleringen ett raderingsmeddelande för att informera andra simuleringar.

Simuleringsprotokollet är textbaserat. Den definieras av en LALR ( 1) kontextfri grammatik. Protokollets semantik är konfederationsberoende, där uppsättningen av klasser, klassattribut, interaktioner och interaktionsparametrar är variabla. Därför kan den syntaktiska representationen av simuleringsprotokollet definieras utan förhandskännedom om semantiken för objekten och interaktionerna hos någon speciell konfederation.

Simulering/ACM Connection Protocol

Anslutningsprotokollet för simulering/ACM tillhandahåller tjänster för att hantera kopplingen mellan en simulering och dess ACM och en metod för informationsutbyte mellan en simulering och dess ACM. Två tjänster styr distributionen av simuleringsprotokollmeddelanden: händelser och utskick. Händelsemeddelanden är tidsstämplade och levereras i en tidsmässigt konsekvent ordning. Utsändningsmeddelanden levereras så snart som möjligt, utan hänsyn till simuleringstid. Ytterligare protokollmeddelanden tillhandahåller anslutningstillstånd, filterregistrering, attributlåskontroll, konfederationssparkontroll, objektresurskontroll och tidskontrolltjänster.

Objekthanteringsprotokoll

Objekthanteringsprotokollet är ett protokoll på peer-nivå som ligger under simuleringsprotokollet och tillhandahåller objekthanteringstjänster. ACM:er använder det endast för att skapa, förvärva, släppa och verifiera objektattribut (av konsistensen i den distribuerade objektdatabasen). Dessa tjänster tillåter AIS att hantera distribuerat objektägande.

Distribuerat objektägande förutsätter att ingen enskild simulering måste äga alla objekt i en konfederation, men många simuleringar kräver kunskap om vissa objekt. En simulering använder meddelanden om uppdatering av simuleringsprotokoll för att upptäcka objekt som ägs av andra simuleringar. Om den här simuleringen är intresserad av objekten kan den spöka dem (spåra deras platser och tillstånd) och modellera interaktioner med dem från ägda objekt.

Lås implementerar attributägande. En primär funktion för objekthanteringsprotokollet är att säkerställa att en simulering endast uppdaterar attribut som den har fått ett lås för. Objekthanteraren i ACM hanterar objekten och objektattributen för de ägda och spökobjekt som är kända för ACM . Tjänster som tillhandahålls av simulerings-/ACM-protokollet används av simuleringarna för att interagera med ACM:s attributlåsningsmekanism. Samordningen av status, begäran, anskaffning och frigivning av objektattribut mellan ACM:er använder objekthanteringsprotokollet. Varje attribut för varje objekt känt för en given ACM har en status som antar ett av tre värden:

  • Låst. En simulering styr attributet och kan uppdatera attributvärdet. En simulering "äger" attributet om det har attributet låst. En simulering "äger" objektet om det har dess id-attribut låst.
  • Olåst. Ingen simulering styr för närvarande attributet. Varje simulering som begär kontroll beviljas kontroll.
  • Borta. Kontrolltillståndet hålls på andra håll i förbundet.

Ur ACM:s perspektiv uppstår objekt genom registreringsprocessen som utförs av dess simulering eller genom upptäckten av objekt som registrerats av andra simuleringar. De initiala tillståndsattributlåsen för registrerade objekt och upptäckta objekt är som följer:

  • Objektregistrering placerar varje objekt-attributpar i låst tillstånd. Simuleringen kan valfritt ange att attribut ska vara i olåst tillstånd.
  • Object Discovery lägger till ett objekt i objektdatabasen som ett spökobjekt. Alla attribut för detta objekt är markerade med statusen borta.

Time Management Protocol

Tidshanteringsprotokollet är också ett protokoll på peer-nivå som ligger under simuleringsprotokollet. Det tillhandahåller tidshanteringstjänster för synkronisering av simuleringstid mellan ACM:er. Protokollet tillhandahåller tjänster för distribuerad koordinering av en simulerings inträde i konfederationen, tidsförlopp och konfederationsbesparingar.

Anslut/avsäga tjänsterna och tidssynkroniseringsmekanismerna beskrivs i avsnittet tidigare. Sparmekanismen ger feltolerans. Samordning krävs för att producera en konsekvent ögonblicksbild av alla ACM, översättare och simuleringar för ett visst värde av simuleringstid.

Meddelandefiltrering

ACM använder simuleringsmeddelandefiltrering för att utvärdera innehållet i ett meddelande som tas emot från konfederationen. ACM levererar meddelanden till sin simulering som är av intresse, och passerar filtreringskriterier och kasserar de som inte är av intresse. ACM filtrerar två typer av meddelanden: uppdateringsmeddelanden och interaktionsmeddelanden.

Uppdatera meddelanden. ACM utvärderar uppdateringsmeddelanden baserat på simuleringens filtreringskriterier för uppdateringsmeddelanden som simuleringen tillhandahåller. Som diskuterats tidigare, när en ACM tar emot ett uppdateringsmeddelande finns det fyra möjliga utfall: (1) ACM kasserar meddelandet, (2) ACM skickar simuleringen ett skapa meddelande, (3) ACM skickar simuleringen uppdateringsmeddelandet , eller (4) ACM skickar simuleringen ett raderingsmeddelande.

Interaktionsmeddelanden. En ACM kan kassera interaktionsmeddelanden på grund av typparametern. Parametern kind har en hierarkisk struktur som liknar objektklassstrukturen. Simuleringen informerar dess ACM om de interaktionstyper som ska klara eller misslyckas med interaktionsfiltret.

Meddelandedistribution

För att minimera meddelandetrafik mellan komponenter i en ALSP-konfederation använder AIS en form av intelligent meddelandedirigering som använder Event Distribution Protocol (EDP). EDP ​​tillåter ACM:er att informera de andra AIS-komponenterna om uppdaterings- och interaktionsfiltren som registrerats av deras simuleringar. När det gäller uppdateringsmeddelanden tillåter distribution av denna information ACM:er att endast distribuera data om klasser (och attribut för klasser) som är av intresse för konfederationen. ABE använder också denna information för att endast skicka information som är av intresse för de komponenter som den betjänar. För interaktionsmeddelanden är processen liknande, förutom att typparametern i interaktionsmeddelandet bestämmer var meddelandet skickas.

Vidare läsning

Hämtad från " https://en.wikipedia.org/w/index.php?title=Aggregate_Level_Simulation_Protocol&oldid=1058676863 "