Architektura na vysoké úrovni - High Level Architecture

Level Architecture High ( HLA ) je standard pro distribuované simulace, použitý při stavbě simulaci větší účel kombinující (federating) několik simulací. Standard byl vyvinut v 90. letech pod vedením amerického ministerstva obrany a později byl převeden na otevřený mezinárodní standard IEEE. Je to doporučený standard v rámci NATO prostřednictvím STANAG 4603. HLA se dnes používá v řadě oblastí, včetně obrany a bezpečnosti a civilních aplikací.

Účelem HLA je umožnit interoperabilitu a opětovné použití. Klíčové vlastnosti HLA jsou:

Možnost propojit simulace běžící na různých počítačích, lokálně nebo široce distribuovaných, nezávisle na jejich operačním systému a implementačním jazyce, do jedné federace.
Možnost specifikovat a používat datové modely pro výměnu informací, Federální objektové modely (FOM), pro různé aplikační domény.
Služby pro výměnu informací pomocí mechanismu publikování a odběru na základě FOM a s dalšími možnostmi filtrování.
Služby pro koordinaci logické (simulační) výměny dat s časovým razítkem.
Služby správy pro inspekci a úpravu stavu federace.

HLA tvoří základ pro vývoj standardizovaných a rozšiřitelných FOM v různých komunitách, například v letectví a obraně.

Architektura určuje následující komponenty.

Součásti federace HLA

Run-time infrastruktury (RTI), která poskytuje standardizovanou sadu služeb prostřednictvím různých programovacích jazyků. Mezi tyto služby patří výměna informací, synchronizace a správa federace
Federáti, kteří jsou individuálními simulačními systémy využívajícími služby RTI.
Federation Object Model (FOM), který určuje třídy objektů a interakci Classes používá pro výměnu dat. FOM může popisovat informace pro libovolnou doménu.

Výše uvedené komponenty společně tvoří Federaci .

Standard HLA se skládá ze tří částí:

Rámec a pravidla IEEE Std 1516-2010 , který určuje deset architektonických pravidel, která budou komponenty nebo celá federace dodržovat.
IEEE Std 1516.1-2010 Federate Specification rozhraní , která specifikuje služby, které budou poskytovány RTI. Služby jsou poskytovány jako C ++ a Java API a také Web Services.
Specifikace šablony objektového modelu IEEE Std 1516.2-2010 , která určuje formát, který mají používat objektové modely HLA, například FOM.

Historie a verze

HLA byla zahájena na počátku devadesátých let minulého století, kdy dr. Anita K. Jonesová , ředitelka obranného výzkumu a inženýrství amerického ministerstva obrany, zadala Úřadu pro modelování a simulaci obrany (DMSO) úkol „zajistit interoperabilitu a znovupoužitelnost obranných modelů“ a simulace “. V roce 1995 DMSO zformuloval vizi pro modelování a simulaci a vytvořil hlavní plán modelování a simulace, který zahrnoval architekturu na vysoké úrovni.

Dva protokoly pro interoperabilitu M&S již existovaly: Distributed Interactive Simulation (DIS), se zaměřením na simulaci úrovně platformy v reálném čase s modelem pevných objektů, a ALSP ( Aggregate Level Simulation Protocol ) se zaměřením na simulaci agregátu se správou času, správou vlastnictví a flexibilitou objektové modely, nazývané konfederační modely. Účelem HLA bylo poskytnout jeden unifikovaný standard, který by splňoval požadavky na interoperabilitu simulace všech amerických komponent DoD.

Vývoj HLA byl založen na čtyřech prototypových federacích: Platform Prototype Federation, Joint Training Protofederation, Analysis Protofederation a Engineering Prototype Federation. Specifikace HLA byla prototypována a vylepšována, dokud nebyla nakonec vydána HLA 1.3. Aby se usnadnilo používání mimo obrannou komunitu, byl HLA poté převeden na standard IEEE, který udržuje organizace Simulation Interoperability Standards Organization (SISO). Aby se usnadnila migrace uživatelům DIS, byl také vyvinut federační objektový model odpovídající pevnému objektovému modelu DIS jako Real-time Platform Reference FOM ( RPR FOM ).

Existují následující verze HLA:

HLA 1.3

HLA 1.3 byla vydána v březnu 1998 společností DMSO. Skládá se z:

Ministerstvo obrany USA, Pravidla Verze 1.3
Ministerstvo obrany USA, specifikace rozhraní architektury na vysoké úrovni, verze 1.3
Ministerstvo obrany USA, šablona objektového modelu architektury na vysoké úrovni, verze 1.3

Americké ministerstvo obrany také publikovalo interpretace pro HLA 1.3:

Ministerstvo obrany USA, Interpretace specifikace rozhraní architektury na vysoké úrovni, verze 1.3, vydání 3

HLA 1516-2000

HLA IEEE 1516-2000 byla vydána v roce 2000 společností IEEE. Skládá se z:

IEEE Std 1516–2000 - Standard pro modelování a simulaci Architektura na vysoké úrovni - Rámec a pravidla
IEEE Std 1516.1–2000 - Standard for Modeling and Simulation High Level Architecture - Federate Interface Specification
IEEE 1516.1–2000 Errata (2003-říjen-16)
IEEE 1516.2-2000-Standard for Modeling and Simulation High Level Architecture-Object Model Template (OMT) Specification

Hlavní vylepšení v IEEE 1516-2000 zahrnovaly FOM na bázi XML s podrobnými specifikacemi datových typů a také vylepšený design DDM.

Standard IEEE 1516-2000 byl také doplněn doporučeným vývojovým procesem a doporučeným procesem VV&A:

IEEE 1516.3-2003-Doporučená praxe pro proces vytváření a spouštění federace architektury na vysoké úrovni (FEDEP). Tento standard se později stane IEEE Std 1730-2010 Distributed Simulation Engineering and Execution Process ( DSEEP )
IEEE 1516.4-2007-Doporučená praxe pro ověřování, validaci a akreditaci federace překrytí procesu vývoje a provádění federace federace na vysoké úrovni

Brzy bylo zjištěno, že standard 1516-2000 měl API, která byla pro každou implementaci RTI mírně odlišná. SISO vytvořilo standard s alternativními, dynamickými linkami kompatibilními (DLC) C ++ a Java API:

SISO-STD-004.1-2004: Standard pro HLA API kompatibilní se standardem Dynamic Link pro specifikaci rozhraní HLA (verze IEEE 1516.1)
SISO-STD-004-2004: Standard pro HLA API kompatibilní se standardem Dynamic Link pro specifikaci rozhraní HLA (v1.3)

API DLC byla později sloučena do hlavního standardu.

HLA 1516-2010 (HLA Evolved)

Standard IEEE 1516-2010 byl publikován v srpnu 2010 IEEE a je běžně známý jako HLA Evolved. Skládá se z:

IEEE 1516–2010 - Standard pro modelování a simulaci architektury na vysoké úrovni - rámec a pravidla
IEEE 1516.1–2010 - Standard pro modelování a simulaci Architektura na vysoké úrovni - Specifikace federativního rozhraní
IEEE 1516.2-2010-Standard pro modelování a simulaci Architektura na vysoké úrovni-Specifikace šablony modelu objektu (OMT)

Mezi hlavní vylepšení IEEE 1516-2010 patří modulární FOM, začlenění DLC API do C ++ a Java, API webových služeb a tolerance chyb.

Strojově čitelné části této verze HLA, jako jsou XML schémata, C ++, Java a WSDL API, stejně jako ukázky FOM/SOM lze stáhnout z oblasti stahování IEEE 1516 na webových stránkách IEEE . Texty úplných standardů jsou členům SISO k dispozici zdarma nebo je lze zakoupit v obchodě IEEE .

HLA 1516-20XX (HLA 4)

Vývoj nové verze HLA zahájil v lednu 2016 SISO a v současné době pokračuje.

Technický přehled

Standard HLA se skládá ze tří částí:

Rámec a pravidla , která specifikují deset architektonických pravidel, která musí federátoři nebo celá federace dodržovat.
Federate Interface Specification , která specifikuje služby, které budou poskytovány RTI. Služby jsou poskytovány jako C ++ a Java API a také Web Services.
Specifikace šablony objektového modelu, která určuje formát, který budou používat objektové modely HLA, například FOM.

Běžná terminologie HLA

Run-time Infrastructure (RTI) : Software, který poskytuje standardizovanou sadu služeb, jak je uvedeno ve specifikaci rozhraní HLA Federate. Existuje sedm servisních skupin.
Federate : Systém, jako je simulace, nástroj nebo rozhraní k živým systémům, který se připojuje k RTI. Příklady nástrojů jsou data loggery a nástroje pro správu. Federát používá služby RTI k výměně dat a synchronizaci s jinými federáty.
Federace : Sada federátů, které se připojují ke stejnému RTI společně se společným FOM.
Provedení federace : relace, kde se sada federatů spouští společně ve federaci s konkrétním cílem pomocí stejných RTI a FOM.
Objektový model federace (FOM) : Dokument, který určuje třídy objektů, třídy interakcí, datové typy a další data, která se používají pro výměnu informací ve federaci. FOM je soubor XML, který dodržuje formát šablony objektového modelu HLA a souvisejícího schématu XML. Pro výměnu dat pro různé aplikační domény se používají různé FOM. Existují standardizované FOM, nazývané referenční FOM, které se běžně používají jako výchozí bod pro vývoj FOM. FOM lze rozvíjet a rozšiřovat modulárně pomocí modulů FOM.
Simulační objektový model (SOM) : Dokument, který určuje třídy objektů, třídy interakcí, datové typy a další data, která konkrétní simulace publikuje a/nebo se přihlásí k odběru ve federaci. SOM je také soubor XML, který sleduje formát šablony objektového modelu HLA a souvisejícího schématu XML. SOM lze také vyvíjet a rozšiřovat modulárně pomocí modulů SOM.
Objekt : Objekty se používají k reprezentaci dat, která jsou po určitou dobu trvalá a která mají atributy, které lze aktualizovat. Jsou definovány ve FOM/SOM pomocí třídy objektů.
Interakce : Interakce se používají k reprezentaci okamžitých událostí s parametry. Odeslanou interakci nelze aktualizovat (na rozdíl od tříd objektů). Jsou definovány ve FOM/SOM pomocí třídy interakce.
Datové typy : Zastoupení a interpretace atributů a parametrů dat je uveden v FOM / SOM pomocí HLA datové typy.
Publikovat : Federát, který publikuje třídu objektů se sadou atributů, může registrovat a odstraňovat instance této třídy objektů a aktualizovat její hodnoty atributů. Federát, který publikuje třídu interakcí, může odesílat interakce této třídy interakcí společně s přidruženými hodnotami parametrů.
Přihlásit se k odběru: Federát, který se přihlásí k odběru třídy objektů se sadou atributů, zjistí registrace a odstranění instancí této třídy objektů a bude dostávat aktualizace předplatených atributů. Federát, který se přihlásí k odběru třídy interakce, bude přijímat interakce této třídy interakcí společně s přidruženými hodnotami parametrů.

Specifikace rozhraní

Služby RTI jsou definovány ve specifikaci rozhraní HLA. Jsou seskupeny do sedmi servisních skupin. Kromě těchto služeb poskytuje objektový model správy (MOM) služby, které umožňují programově kontrolovat a upravovat stav federace.

Většina RTI se skládá z centrální komponenty RTI (CRC), což je spustitelný soubor, a místních komponent RTI (LRC), což jsou knihovny, které používají federátoři. Služby jsou poskytovány prostřednictvím C ++ nebo Java API a také pomocí webových služeb. V API C ++ a Java jsou služby vyvolávány pomocí volání instance třídy RTI Ambassador. RTI poskytuje informace federátu pomocí zpětných volání, která jsou doručována pomocí volání na instanci třídy Federate Ambassador. V rozhraní Web Services API, definovaném pomocí WSDL , provádí federace volání a zpětná volání pomocí požadavků a odpovědí webových služeb.

Níže popsané skupiny služeb se zaměřují na klíčové služby. Výjimky a upozornění nejsou zahrnuty.

Služby správy federace

Účelem služeb správy federace, popsaných v kapitole 4 specifikace rozhraní HLA, je správa operací federace a operací v rámci celé federace, jako jsou synchronizační body a ukládání/obnovení.

Jedna sada služeb správy federace spravuje připojení k RTI, provádění federace a sadu spojených federací. Klíčové služby jsou:

Připojte a odpojte od RTI
CreateFederationExecution a DestroyFederationExecution, které se používají k vytvoření a zničení spuštění federace
JoinFederationExecution a ResignFederationExecution, které federát používá k připojení a ukončení federace.
ConnectionLost, který používá RTI k informování federátu, že kvůli chybě ztratil připojení k spuštění federace
ListFederationExecutions, který se používá k načtení seznamu dostupných provedení federace pro RTI

Další sada služeb se týká synchronizačních bodů. Jedná se o události v celé federaci, kde jsou všichni nebo vybraní federátoři povinni dokončit operaci, jako je inicializace scénáře, než může pokračovat provádění. Klíčové služby jsou:

RegisterFederationSynchronizationPoint, který se používá k registraci synchronizačního bodu
AnnounceSynchronizationPoint, který používá RTI k informování federátů o tom, že byl zaregistrován synchronizační bod
SynchronizationPointAchieved, který federát používá k označení, že dosáhl bodu synchronizace
FederationSynchronized, který používá federace RTI k informování federací o synchronizaci federace, tj. Všechny federace dosáhly bodu synchronizace.

Ještě další sada služeb se týká ukládání a obnovy spuštění federace. Operace uložení vyžaduje, aby RTI i každá federace provedla uložení svého interního stavu. Operace obnovy vyžaduje, aby RTI i každá federace provedla obnovu svého vnitřního stavu. Klíčové služby jsou:

Uložit:

RequestFederationSave, který se používá k zahájení uložení federace
InitiateFederateSave, který používá RTI k upozornění federátů na zahájení ukládání svého stavu
FederateSaveComplete, který bude volán federátem po dokončení ukládání jeho stavu.
FederationSaved, který používá RTI k upozornění federátů na uložení federace

Obnovit:

RequestFederationRestore, který se používá k zahájení obnovy federace
InitiateFederateRestore, který používá RTI k upozornění federátů na zahájení obnovy stavu
FederateRestoreComplete, který bude volán federátem, jakmile dokončí obnovu svého stavu.
FederationRestored, který používá RTI k upozornění federátů na obnovení federace

Služby správy prohlášení

Účelem služeb správy deklarace, popsaných v kapitole 5 specifikace rozhraní HLA, je umožnit federátům deklarovat, jaké informace chtějí publikovat (odesílat) a odebírat (přijímat) na základě tříd objektů a interakcí ve FOM. RTI používá tyto informace k směrování aktualizací a interakcí k předplatitelským federátům. U třídy objektů se publikování a předplatné provádí pro konkrétní sadu atributů. U tříd interakcí je publikována a přihlášena k odběru celá interakce, včetně všech parametrů. Klíčové služby jsou:

PublishObjectClassAttributes, který se používá k publikování sady atributů pro danou třídu objektů.
SubscribeObjectClassAttributes, který se používá k přihlášení k odběru sady atributů pro danou třídu objektů.
PublishInteractionClass, který se používá k publikování třídy interakce včetně všech parametrů
SubscribeInteractionClass, který se používá k přihlášení k odběru třídy interakce včetně všech parametrů

Služby správy objektů

Účelem služeb Object Management, popsaných v kapitole 6 specifikace rozhraní HLA, je umožnit federátům sdílet informace o instancích objektů a vyměňovat si interakce.

Názvy instancí objektů lze rezervovat nebo je lze generovat automaticky. Federátoři mohou registrovat instance objektů zadaných tříd objektů, které jsou poté objeveny přihlášením federátů. Atributy těchto instancí objektů lze aktualizovat. Tyto aktualizace se projeví u odběratelských federátů. Interakce lze odesílat. Tyto interakce budou doručeny předplatitelským federátům. Klíčové služby jsou:

Objekty:

ReserveObjectInstanceName, který se používá k rezervaci názvu, který se má použít pro instanci objektu
RegisterObjectInstance, který se používá k registraci instance objektu konkrétní třídy objektu, buď s vyhrazeným názvem, nebo automaticky generovaným názvem.
DiscoverObjectInstance, který používá RTI k upozornění federátů, kteří se přihlásili k odběru konkrétní třídy objektů, že byla zaregistrována nová instance objektu.
DeleteObjectInstance, který se používá k odstranění instance objektu
RemoveObjectInstances, které používají RTI k upozornění federátů, že instance objektu byla odebrána

Atributy:

UpdateAttributeValues, který se používá k poskytnutí aktualizovaných hodnot atributů pro instanci objektu
ReflectAttributeValues, který používá RTI k upozornění federátů k odběru konkrétních atributů aktualizovaných hodnot.

Interakce:

SendInteraction, který se používá k odeslání interakce konkrétní třídy interakce, včetně hodnot parametrů.
ReceiveInteraction, který používá RTI k dodání interakce, včetně hodnot parametrů, k federování předplatného konkrétní třídy interakce

Služby správy vlastnictví

Účelem služeb správy vlastnictví, popsaných v kapitole 7 specifikace rozhraní HLA, je dynamicky spravovat federaci, která simuluje jaký aspekt instance objektu. V HLA může aktualizovat daný atribut dané instance objektu pouze jeden federát. Tento federát je považován za vlastníka atributu. Federát, který zaregistruje novou instanci objektu, bude automaticky vlastníkem všech atributů, které publikuje. V některých případech mohou být atributy instance objektu neznámé, tj. Nevlastněné žádným federátem.

Správa vlastnictví poskytuje služby pro převod vlastnictví jednoho nebo několika atributů za běhu, což může zahrnovat federální odprodej atributu a další federální získání atributu. Existují dva hlavní vzorce: „pull“, které jsou iniciovány přebírajícím federátem, a „push“, které jsou iniciovány zbavujícím se federátem.

Klíčové služby pro zahájení vlastnictví „pull“ jsou:

AttributeOwnershipAcquisitionIfAvailable, který používá federát, který si přeje získat vlastnictví neznámých atributů.
AttributeOwnershipAcquisition, který používá federát, který si přeje požádat o vlastnictví potenciálně vlastněného atributu

Klíčové služby pro zahájení „push“ vlastnictví jsou:

AttributeOwnershipDivestitureIfWanted, který používá federát, který si přeje zbavit se atributů, pouze pokud existuje nějaký jiný federát, který je připraven získat vlastnictví těchto atributů.
NegotiatedAttributeOwnershipDivestiture, který je podobný, ale může také způsobit, že se RTI pokusí najít nového majitele.
UnconditionalAttributeOwnershipDivestiture, který používá federát, který se chce vzdát vlastnictví, i když nelze najít nového vlastníka.

Všechny instance objektů mají předdefinovaný atribut nazvaný HLAPrivilegeToDeleteObject. Pouze vlastník tohoto atributu pro instanci objektu smí odstranit instanci objektu. Vlastnictví tohoto atributu lze převést za běhu pomocí výše uvedených operací.

Služby správy času

Výměna informací ve federaci HLA probíhá v reálném čase s okamžitým doručením zpráv (příjem objednávky, RO), pokud není povolena správa času HLA. Účelem HLA Time Management, popsaného v kapitole 8 specifikace rozhraní HLA, je zaručit kauzalitu a správnou a konzistentní výměnu časově označených zpráv (aktualizací a interakcí) v Time Stamp Order (TSO), bez ohledu na to, zda federace provádí v reálném čase, rychleji než v reálném čase, pomaleji než v reálném čase nebo co nejrychleji.

Některé důležité koncepty v HLA Time Management jsou:

Logický čas : Časová osa v HLA, počínaje nulou. Logický čas se používá pro časová razítka a operace Time Management. Logickou časovou osu lze namapovat na čas scénáře federace. Příkladem takového mapování je nechat nulu představovat čas scénáře 8:00 1. ledna 1066 a přírůstek o jednu představovat jednu sekundu scénáře.

Lookahead : Časový interval určující nejnižší čas v budoucnosti, za který bude federát vytvářet zprávy. U federátu s pevným časovým krokem je to obvykle délka časového kroku.

Uděleno : Federát uděluje (povoluje postup) konkrétnímu logickému času, když byly doručeny všechny zprávy s časovým razítkem do té doby. Federát pak může v budoucnu bezpečně začít počítat zprávy s časovým razítkem. Toto časové razítko nesmí být dříve než přidělený čas plus federální vyhledávací hlava.

Postup : Když federace dokončí produkci dat po stanovenou dobu plus hledací hlavu, může požádat o přechod na pozdější dobu, což také znamená, že slibuje, že nebude produkovat žádné další zprávy s časovým razítkem kratším než požadovaný čas plus hledáčku. Federace je nyní v postupujícím stavu.

Časová regulace : Federace, která odesílá události s časovým razítkem, je považována za časově regulovanou, protože časový posun jinými federáty může být tímto regulován.

Časově omezený : Federát, který přijímá časově řízené události, je považován za časově omezený, protože příjem zpráv s časovým razítkem omezuje jeho časový posun.

Hlavní zásady HLA Time Managementu jsou následující:

Každá federace přiřadí zprávám (aktualizacím a interakcím) při jejich odeslání časové razítko, což indikuje, pro který scénář je zpráva platná.
Federáti žádají svolení RTI, aby svůj čas prodloužili.
RTI spravuje doručování zpráv a uděluje federátům časový předstih, aby byly zprávy doručovány v pořadí časových razítek a aby federátům v minulosti nepřišly žádné zprávy s časovým razítkem.

Příklad Lookahead, udělený a postupující:

Federát používá pevný časový krok 10 a má Lookahead 10.
Federal je udělen logickému času 50 podle RTI. RTI tedy zaručuje, že všechny zprávy s časovým krokem menším nebo rovným 50 byly doručeny federátu.
Federát má nyní všechna potřebná data ke správnému výpočtu a odesílání zpráv po stanovenou dobu plus Lookahead, tj. 60.
Když federát odeslal všechny zprávy s časovým razítkem 60, požaduje, aby byl posunut na čas 60. Tím slibuje, že nebude odesílat žádné zprávy s časovým razítkem menším než 70.
RTI doručuje federaci všechny zprávy s časovým razítkem menším nebo rovným 60. Poté uděluje federaci čas 60.
Atd.

Pokud alespoň jedna federace ve federaci provádí stimulaci, tj. Koreluje jejich požadavky na časový posun s hodinami reálného času, federace může běžet v reálném čase nebo v měřítku v reálném čase. Bez stimulace poběží federace co nejrychleji, což se používá například v simulaci Monte Carlo.

Mezi klíčové služby patří:

EnableTimeConstrained a EnableTimeRegulate, které umožňuje tyto režimy pro federát
TimeAdvanceRequest, kdy federát požaduje postup do zadaného logického času
TimeAdvancedGrant, přičemž RTI informuje federát, že je udělen na určený logický čas.
EnableAsynchronousDelivery, které umožňuje doručování zpráv o přijetí objednávky jak v případě, že je federát ve stavu přidělení, tak v postupu.

U simulace řízené událostmi je také možné, aby federát požádal o postup na další událost pomocí následující služby:

NextMessageRequest, přičemž federátor požaduje, aby byl postoupen k časovému razítku další zprávy, která má být doručena do federátu, nebo k určenému logickému času, podle toho, co má nižší časové razítko.

Dalším důležitým konceptem je Greatest Available Logical Time (GALT). Největší doba, kterou lze každému federátu udělit, závisí na době, kdy byly uděleny jiným federátům, a také na jejich hledáčku. GALT pro federáta určuje, jak daleko může být federát udělen, aniž byste museli čekat na udělení dalších federátů. To je zvláště zajímavé pro federát, který se připojí pozdě do časově řízené federace.

Klíčové služby pro GALT jsou:

QueryGALT, který vrací GALT pro volající federaci.

Mezi pokročilejší služby patří:

FlushQueueRequest, kdy federát může požadovat doručení všech zpráv s časovým razítkem ve frontě, bez ohledu na to, jak daleko v budoucnosti jejich časové razítko je.
Zatáhnout, čímž může federát požádat o stažení již odeslané zprávy. To je užitečné v optimistické simulaci.

Služby správy distribuce dat (DDM)

Účel DDM, popsaný v kapitole 9 specifikace rozhraní HLA, je zvýšit škálovatelnost federací provedením dodatečného filtrování předplatených dat nad rámec předplatných tříd a atributů. Filtrování může být založeno na spojitých hodnotách (jako zeměpisná šířka a délka) nebo na diskrétních hodnotách (jako značka automobilu).

Klíčové koncepty DDM jsou:

Dimenze : pojmenovaný interval (0..n) používaný pro filtrování, přičemž hodnoty začínají 0 a končí horní mezí n. Data v simulační doméně jsou mapována do jedné nebo více dimenzí. Dimenze pro geografické filtrování mohou být například LatitudeDimension a LongitudeDimension. Dimenzí pro filtrování podle značky automobilu může být CarBrandDimension.

Funkce normalizace : funkce, která mapuje vstupní hodnoty na celočíselné hodnoty, které mají být použity v dimenzi. Příkladem je, že funkce normalizace pro LatitudeDimension by mohla mapovat hodnotu zeměpisné šířky v rozmezí od -90,0 do +90,0 na celé číslo v rozsahu 0..179. Normalizační funkce pro CarBrandDimension by mohla mapovat sadu automobilových značek Kia, Ford, BMW a Peugeot na celé číslo v rozsahu 0..3.

Rozsah : interval na dimenzi, určený dolní mezí (včetně) a horní hranicí (výlučně).

Region : sada rozsahů, z nichž každý se vztahuje k určité dimenzi. Ve výše uvedeném příkladu by oblast mohla sestávat z rozsahu (3..5) pro LatitudeDimension (55..65) pro LongitudeDimension a (0..1) pro CarBrandDimension. Za běhu jsou implementace oblastí (objekty) vytvořeny tak, aby reprezentovaly oblasti. Rozsahy oblasti lze v průběhu času upravit.

Překrývání oblastí : dvě oblasti se překrývají, pokud se pro všechny dimenze, které mají společné, jejich rozsahy překrývají.

Za běhu může federát poskytnout regiony při přihlášení k atributům a interakcím tříd objektů. Regiony se také používají při odesílání aktualizací atributů a interakcí. Při použití DDM budou aktualizace atributů a interakce doručovány pouze v případě překrývání oblasti.

Klíčové služby pro regiony jsou:

CreateRegion, který se používá k vytvoření oblasti se zadanou sadou dimenzí.
DeleteRegion, který se používá k odstranění oblasti.
CommitRegionModifications, který se používá ke změně rozsahů dimenze pro Region.

Klíčové služby pro výměnu aktualizací atributů pomocí DDM jsou:

RegisterObjectInstanceWithRegions, který se používá k registraci instance objektu s oblastmi spojenými s jeho atributy.
AssociateRegionsForUpdates, který se používá k přidružení oblastí k atributům instance objektu.
SubscribeObjectClassAttributesWithRegions, který se používá k přihlášení k odběru atributů objektů, kde se oblasti použité pro předplatné překrývají s oblastmi atributů.

Klíčové služby pro výměnu interakcí s DDM jsou:

SubscribeInteractionClassWithRegions, který se používá k odběru interakcí, kde se oblasti použité pro předplatné překrývají s oblastmi interakcí.
SendInteractionsWithRegions, který se používá k odesílání interakcí s přidruženými oblastmi.

Pomocné služby

Služby podpory HLA, popsané v kapitole 10 Specifikace rozhraní HLA, poskytují řadu podpůrných služeb. Tyto zahrnují:

Získání rukojetí (referencí), které mají být použity ve výše uvedených voláních služeb.
Nastavení různých runtime přepínačů, zejména pro upozornění (oznámení).
Řízení doručování zpětných volání.

Objektový model správy

Účelem objektu Object Management, popsaného v kapitole 11 specifikace rozhraní HLA, je poskytovat služby pro správu federace. To se provádí pomocí tříd objektů a interakcí MOM. Objekty MOM jsou definovány ve speciálním modulu FOM nazývaném MIM, který je automaticky načítán pomocí RTI. Mezi klíčové funkce MOM patří:

Seznam a kontrola vlastností federátů.
Zkontrolujte vlastnosti federace.
Získejte obsah aktuálních modulů FOM a FOM.
Zkontrolujte stav správy času.
Zkontrolujte a upravte publikace a předplatné federátů.
Zkontrolujte určité údaje o výkonu.
Zkontrolujte, který federát volá HLA služby.
Zkontrolujte stav synchronizačních bodů.

Šablona objektového modelu (OMT)

OMT je šablona používaná k popisu federačních objektových modelů (FOM) a simulačních objektových modelů (SOM). FOM a SOM mohou být reprezentovány v tabulkovém formátu nebo pomocí XML. Druhý formát se používá, když je FOM načten do RTI.

V dřívějších verzích HLA byly FOM monolitické, ale současná verze standardu podporuje modulární FOM, tj. Několik modulů pokrývajících různé aspekty výměny informací, může být poskytnuto RTI.

Standard obsahuje řadu předdefinovaných tříd, datových typů, rozměrů a typů přepravy. Ty jsou k dispozici v modulu FLA HLAstandardMIM.xml. Předdefinované koncepty mají předponu HLA, například HLAobjectRoot a HLAunicodeString.

Pro OMT existují tři různá schémata XML:

Schéma OMT DIF XML, které ověřuje, zda dokument OMT dodržuje základní formát OMT, ale ne, že je úplný a má referenční integritu.
Schéma OMT FDD XML, které ověřuje, že dokument OMT obsahuje dostatek informací, které mohou být užitečné pro RTI. Všimněte si, že toto schéma je uvedeno ve specifikaci rozhraní.
Schéma shody OMT, které ověřuje, zda je dokument OMT úplný a má referenční integritu.

Identifikační tabulka

Účelem identifikační tabulky je poskytnout metadata o modelu, usnadnit opětovné použití FOM/SOM nebo federátů.

Ukázka identifikační tabulky HLA

Jsou zadána následující pole:

Obecné: Název, Typ (FOM/SOM), Verze, Datum úpravy, Klasifikace zabezpečení, Omezení vydání, Účel, Doména aplikace, Popis, Omezení používání a Historie použití
Klíčová slova: Hodnoty klíčových slov a použitá taxonomie
Bod kontaktu (POC): Typ (primární autor/přispěvatel/navrhovatel/sponzor/autorita vydání/technický POC), název POC, organizace POC, telefon POC, e -mail POC
Reference: Typ (textový dokument/tabulka/soubor aplikace Powerpoint/samostatný FOM/závislý FOM/složený z FOM), identifikace (název dokumentu nebo název FOM)
jiný
Glyf (ikona)

Tabulka struktur tříd objektů

Účelem tabulky struktury tříd objektů je určit hierarchii tříd (podtřídy/nadtřídy) tříd objektů, které se používají k vytváření instancí objektů ve federaci HLA. Atributy tříd objektů se dědí ze supertříd na podtřídy na základě této hierarchie. Kořen stromu tříd objektů je známý jako HLAobjectRoot. Příklad plně kvalifikovaného názvu třídy objektu je HLAobjectRoot.Car.ElectricCar

Ukázka tabulky tříd objektů HLA

Pro třídu objektů v hierarchii jsou určena následující pole:

název
Publikace (Publikovat/Přihlásit se/PublikovatPředplatit/Žádná)

Tabulka atributů

Účelem tabulky atributů je určit atributy, které jsou k dispozici pro danou třídu objektů. Vzhledem k tomu, že atributy jsou zděděny, třída objektu bude mít sjednocení všech atributů, které jsou lokálně definovány ve třídě objektů nebo zadány v jakékoli přímé nebo nepřímé nadtřídě.

Ukázka tabulky atributů HLA

Pro atribut jsou zadána následující pole

Název třídy objektu, pro který je definován
Název atributu
Datový typ, definovaný v tabulce datových typů (viz níže)
Typ aktualizace (statický/periodický/podmíněný/bez aktualizace)
Aktualizovat podmínku
D/A (Divest/Acquire/NoTransfer/DivestAcquire): Zda může být atribut zbaven nebo získán pomocí HLA Ownership Services
P/S (Publikovat/Přihlásit se/PublikovatSubscribe/Žádný): Zda může být atribut publikován a/nebo přihlášen k odběru. V SOM se tyto informace týkají popsané federace, ve FOM se týkají celé federace.
Dostupné rozměry
Přeprava (Spolehlivá/BestEffort/další přepravy popsané v tabulce Doprava)
Order (Receive/TimeStamp): Delivery order for attribute updates.

Tabulka struktury třídy interakce

Účelem tabulky struktury tříd interakcí je určit hierarchii tříd (podtřídy/nadtřídy) tříd interakcí, které se používají k výměně interakcí ve federaci HLA. Parametry třídy interakce se dědí ze supertříd na podtřídy na základě této hierarchie. Kořen stromu tříd interakcí je známý jako HLAinteractionRoot. Příklad plně kvalifikovaného názvu třídy interakce je HLAinteractionRoot.CarCommand.Start.

Ukázka tabulky tříd interakce HLA

Pro třídu interakcí v hierarchii jsou zadána následující pole:

název
Publikace (Publikovat/Přihlásit se/PublikovatPředplatit/Žádná)

Tabulka parametrů

Účelem tabulky parametrů je určit parametry, které jsou k dispozici pro danou třídu interakcí. Vzhledem k tomu, že parametry jsou zděděny, třída interakce bude mít sjednocení všech parametrů, které jsou lokálně definovány ve třídě interakce nebo zadány v jakékoli přímé nebo nepřímé nadtřídě.

Ukázka tabulky parametrů HLA

Tabulka rozměrů

Účelem tabulky dimenzí je určit dimenze DDM používané pro atributy a třídy interakcí.

Tabulka časové reprezentace

Účelem tabulky časové reprezentace je určit datové typy používané službami Time Management.

Tabulka značek dodaná uživatelem

Při volání určitých služeb HLA lze zadat uživatelem zadaný tag. Účelem tabulky značek dodávaných uživatelem je určit datové typy těchto značek.

Synchronizační tabulka

Účelem synchronizační tabulky je určit synchronizační body používané ve federaci.

Tabulka typů přepravy

Účelem tabulky typů dopravy je určit dostupné druhy dopravy. Existují dva předdefinované typy dopravy: HLAreliable a HLAbestEffort.

Aktualizujte tabulku sazeb

Účelem tabulky rychlostí aktualizací je určit dostupné maximální rychlosti aktualizací.

Přepíná stůl

Chování runtime modulu RTI lze ovládat pomocí řady předdefinovaných přepínačů. Účelem tabulky přepínačů je poskytnout počáteční hodnoty pro tyto přepínače. Některé přepínače lze také aktualizovat za běhu.

Typy dat

Účelem tabulek datových typů je poskytnout specifikace datových typů použitých pro atributy, parametry, rozměry, časové zastoupení, tagy dodané uživatelem a synchronizační body. Existuje šest kategorií datových typů se samostatným tabulkovým formátem pro každý z nich.

Základní tabulka reprezentace dat

Účelem základní tabulky reprezentace dat je poskytnout binární reprezentace pro použití v jiných tabulkách. Ve standardu HLA je k dispozici řada předdefinovaných základních datových typů: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteoTLE64AT, HLAfloat Sada základních datových typů obvykle není rozšířena o uživatelem definované základní datové typy.

Jednoduchá tabulka datových typů

Ukázka tabulky jednoduchých datových typů HLA

Účelem jednoduché tabulky datových typů je popsat jednoduché skalární datové položky. Ve standardu HLA je k dispozici řada předdefinovaných jednoduchých datových typů: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time a HLAfloat64time. Je běžné zahrnout uživatelem definované jednoduché datové typy do FOM.

Tabulka výčtů datových typů

Ukázka tabulky výčtů datových typů HLA

Účelem výčtové tabulky datových typů je popsat datové prvky, které mohou nabývat konečných diskrétních sad hodnot. Standardem je jeden předdefinovaný výčtový datový typ: HLAboolean. Je běžné zahrnout uživatelem definované výčtové datové typy do FOM.

Tabulka datových typů pole

Ukázka tabulky datových typů pole HLA

Účelem tabulky vyjmenovaných datových typů je popsat pole datových prvků (jednoduché, výčtové, pole, pevné záznamy nebo alternativní záznamy). Ve standardu HLA je k dispozici řada předdefinovaných jednoduchých datových typů: HLAASCIIstring, HLAunicodeString, HLAopaqueData a HLAtoken. Je běžné zahrnout uživatelem definované datové typy polí do FOM.

Opravená tabulka datových typů záznamů

Ukázka tabulky datových typů pevných záznamů HLA

Účelem tabulky datových typů pevných záznamů je popsat záznamy s pevnou sadou datových prvků (jednoduché, výčtové, pole, pevné záznamy nebo variantní záznamy). Je běžné zahrnout uživatelem definované jednoduché datové typy do FOM. Ve standardu HLA nejsou k dispozici žádné předdefinované jednoduché datové typy.

Tabulka datových typů záznamů variant

Tabulka poznámek

Účelem poznámek k tabulce je poskytnout anotace a další popis položek v jiných tabulkách.

Pravidla HLA

Pravidla HLA popisují odpovědnost federací a federací, které se připojí.

Federace musí mít HLA federační objektový model (FOM), zdokumentovaný v souladu se šablonou objektového modelu HLA (OMT).
Ve federaci musí být veškeré zastoupení objektů ve FOM ve federátech, nikoli v run-time infrastruktuře (RTI).
Během provádění federace bude veškerá výměna dat FOM mezi federáty probíhat prostřednictvím RTI.
Během provádění federace budou federátoři komunikovat s infrastrukturou run-time (RTI) v souladu se specifikací rozhraní HLA.
Během provádění federace bude atribut instance objektu v daném okamžiku vlastněn pouze jedním federátem.
Federáti budou mít objektový model simulace HLA (SOM), zdokumentovaný v souladu se šablonou objektového modelu HLA (OMT).
Federáti musí být schopni aktualizovat a/nebo odrážet jakékoli atributy objektů ve svém SOM a odesílat a/nebo přijímat interakce s objekty SOM externě, jak je uvedeno v jejich SOM.
Federátoři musí být schopni dynamicky převádět a/nebo přijímat vlastnictví atributu během provádění federace, jak je uvedeno v jejich SOM.
Federáti budou moci měnit podmínky, za kterých poskytují aktualizace atributů objektů, jak je uvedeno v jejich SOM.
Federáti budou schopni řídit místní čas způsobem, který jim umožní koordinovat výměnu dat s ostatními členy federace.

Vyvinuto HLA

Standard IEEE 1516 byl revidován v rámci skupiny SISO HLA-Evolved Product Development Group a byl schválen 25. března 2010 radou IEEE Standards Activities Board. Revidovaný standard IEEE 1516–2010 obsahuje aktuální standardní interpretace DoD a EDLC API, rozšířenou verzi SISO DLC API. Mezi další zásadní vylepšení patří:

Rozšířená podpora XML pro FOM/SOM, jako jsou schémata a rozšiřitelnost
Služby podpory odolnosti vůči chybám
Podpora webových služeb (WSDL)/API
Modulární FOM
Snížení rychlosti aktualizace
Pomocníci pro kódování
Rozšířená podpora pro další přepravu (jako QoS, IPv6, ...)
Standardizované časové reprezentace

Federální shoda

Aby byla zajištěna správná interakce mezi simulacemi, je definován způsob testování federální shody. To zahrnuje zajištění toho, aby každá třída a interakce uvedená v SOM pro konkrétní federaci byla použita podle popsaného použití, „PublishSubscribe“, „Publish“, „Subscribe“ nebo „None“.

STANAG 4603

HLA (jak v aktuální verzi IEEE 1516, tak v její starší verzi „1.3“) je předmětem standardizační dohody NATO (STANAG 4603) pro modelování a simulaci: Standardy modelování a simulační architektury pro technickou interoperabilitu: architektura na vysoké úrovni (HLA) .

Související standardy

Základní objektový model

Základní Object Model (BOM), SISO-STD-003-2006 je příbuzný standardem SISO poskytovat lepší opětovné použití a uspořadatelnost pro HLA simulace. Poskytuje způsob, jak specifikovat koncepční modely a jak je namapovat na HLA FOM.

Alternativy

Pokud jde o průmysl distribuovaného modelování a simulace (DM&S), nejčastěji používanou alternativou k HLA, pro simulaci vojenských platforem v reálném čase, je Distributed Interactive Simulation (DIS), IEEE 1278.1-2012, simulační protokol. Většina prodejců HLA RTI má ve svých produktech také DIS. Pokud jde o aplikace middlewaru, které se nejvíce shodují s funkcemi HLA, jako je například funkce publikování a odběru (P&S), podívejte se na Data Distribution Service (DDS), která sdílí mnoho stejných vlastností, ale má otevřený protokol on-the-wire pro interoperabilitu systému.

Kritika

HLA je middleware orientovaný na zprávy, který je definován jako sada služeb poskytovaných rozhraním API C ++ nebo Java . Neexistuje žádný standardizovaný protokol on-the-wire. Účastníci federace musí používat knihovny RTI od stejného poskytovatele a obvykle také stejné verze, což je v některých případech vnímáno jako nevýhoda. Většina současných nástrojů také poskytuje propojení prostřednictvím soketů.

Languages

In other projects