Protokół symulacji poziomu agregatu

Aggregate Level Simulation Protocol (ALSP) to protokół i oprogramowanie pomocnicze, które umożliwia wzajemne współdziałanie symulacji. Zastąpiony architekturą wysokiego poziomu (symulacja) (HLA) , był używany przez wojsko USA do łączenia symulacji analitycznych i szkoleniowych.

ALSP składa się z:

  1. ALSP Infrastructure Software (AIS), które zapewnia obsługę rozproszonych symulacji w czasie wykonywania i zarządzanie nimi;
  2. Interfejs ALSP wielokrotnego użytku składający się z ogólnych protokołów komunikatów wymiany danych; I
  3. Uczestniczące symulacje przystosowane do użytku z ALSP.

Historia

W 1990 roku Agencja Zaawansowanych Projektów Badawczych w Obronie (DARPA) zatrudniła korporację MITRE konstruktywnych do zbadania zastosowania zasad rozproszonej interaktywnej symulacji zastosowanych w SIMNET do symulacji szkoleniowych na poziomie agregatów. Opierając się na wysiłkach prototypowych, w 1991 roku przeprowadzono społecznościowy eksperyment mający na celu rozszerzenie SIMNET w celu połączenia symulacji bitwy korpusu armii amerykańskiej (CBS) i symulacji wojny powietrznej Sił Powietrznych Stanów Zjednoczonych (AWSIM) . Sukces prototypu i uznanie przez użytkowników wartości tej technologii dla społeczności szkoleniowej zaowocowało opracowaniem oprogramowania produkcyjnego. Pierwsza konfederacja ALSP, zapewniająca interakcje powietrze-ziemia między CBS i AWSIM, wsparła trzy główne ćwiczenia w 1992 roku.

Do 1995 roku ALSP przeszedł na program obejmujący wiele usług z symulacjami reprezentującymi armię amerykańską (CBS), siły powietrzne USA (AWSIM), marynarkę wojenną Stanów Zjednoczonych (RESA), korpus piechoty morskiej Stanów Zjednoczonych (MTWS), wojnę elektroniczną ( JECEWSI ) . , logistyka ( CSSTSS ) i wywiad ( TACSIM ). Program przeszedł również od nacisku DARPA na badania i rozwój do głównego nurtu zarządzania przez Biuro Wykonawcze Armii Stanów Zjednoczonych ds. Symulacji, Szkolenia i Instrumentacji ( PEO STRI )

Składki

W ramach projektu ALSP opracowano i zademonstrowano kluczowe aspekty symulacji rozproszonej, z których wiele zastosowano przy opracowywaniu HLA.

  • Brak centralnego węzła, aby symulacje mogły dowolnie dołączać i odchodzić od konfederacji
  • Dystrybucja geograficzna, w której symulatory mogą być dystrybuowane do różnych lokalizacji geograficznych, a jednocześnie ćwiczyć w tym samym symulowanym środowisku
  • Własność obiektów, więc każda symulacja kontroluje własne zasoby, strzela z własnej broni i określa odpowiednie uszkodzenia swoich systemów podczas ostrzału
  • Protokół oparty na komunikatach do dystrybucji informacji z jednej symulacji do wszystkich innych symulacji.
  • Zarządzanie czasem tak, aby czasy dla wszystkich symulacji wydawały się użytkownikom takie same i aby zachowana była przyczynowość zdarzeń – zdarzenia powinny występować w tej samej kolejności we wszystkich symulacjach.
  • Zarządzanie danymi umożliwia wszystkim symulacjom udostępnianie informacji w powszechnie zrozumiały sposób, nawet jeśli każda z nich ma własną reprezentację danych. Obejmuje to wiele symulacji kontrolujących atrybuty tego samego obiektu.
  • Architektura, która pozwala symulacjom na dalsze korzystanie z istniejących architektur podczas uczestnictwa w konfederacji ALSP.

Motywacja

W 1989 roku Centrum Przygotowania Wojowników (WPC) w Einsiedlerhof w Niemczech było gospodarzem skomputeryzowanych ćwiczeń wojskowych ACE-89. Agencja Obronnych Zaawansowanych Projektów Badawczych ( DARPA ) wykorzystała ACE-89 jako okazję do wprowadzenia technologii, finansując wdrożenie Internetowej Symulacji Obronnej (DSI). Telekonferencje wideo w pakietach po raz pierwszy umożliwiły spotkanie oficerów generalnych państw NATO twarzą w twarz podczas ćwiczeń wojskowych; zostało to dobrze przyjęte. Ale aplikacja DSI, dystrybucja Ground Warfare Simulation (GRWSIM), była mniej skuteczna. Symulacja GRWSIM była zawodna, a jej rozproszona baza danych była niespójna, co obniżało skuteczność ćwiczenia.

DARPA finansowała rozwój rozproszonego systemu szkolenia czołgów o nazwie SIMNET , w którym indywidualni, skomputeryzowani trenerzy załóg czołgów byli połączeni przez sieci lokalne i DSI w celu współpracy na jednym, wirtualnym polu bitwy. Sukces SIMNET, rozczarowanie ACE-89 i chęć połączenia istniejących symulacji bojowych skłoniły DARPA do rozpoczęcia badań prowadzących do ALSP.

Podstawowe założenia

DARPA sponsorowała projekt ogólnego interfejsu między dużymi, istniejącymi symulacjami walki na poziomie zbiorczym. Symulacje walki na poziomie zbiorczym wykorzystują Lanchestrian zamiast indywidualnych modeli broni fizycznej i są zwykle używane do szkolenia na wysokim poziomie. Pomimo różnic reprezentacyjnych, kilka zasad SIMNET miało zastosowanie do symulacji na poziomie agregatów:

  • Dynamiczna konfigurowalność. Symulacje mogą dołączać i opuszczać ćwiczenie bez ograniczeń.
  • Podział geograficzny. Symulacje mogą znajdować się w różnych lokalizacjach geograficznych, a jednocześnie działać na tym samym logicznym terenie.
  • Podmioty autonomiczne. Każda symulacja kontroluje własne zasoby, strzela z własnej broni, a w przypadku trafienia jednego z jej obiektów przeprowadza lokalną ocenę uszkodzeń.
  • Komunikacja przez przekazywanie wiadomości. Symulacja wykorzystuje protokół przekazywania komunikatów do dystrybucji informacji do wszystkich innych symulacji.

Wyzwanie ALSP miało wymagania wykraczające poza wymagania SIMNET:

  • Zarządzanie czasem symulacji. Zwykle czas symulacji jest niezależny od czasu zegara ściennego. Aby wyniki rozproszonej symulacji były „poprawne”, czas musi być spójny we wszystkich symulacjach.
  • Zarządzanie danymi. Schematy reprezentacji stanu wewnętrznego różnią się w istniejących symulacjach, co wymaga wspólnego systemu reprezentacji oraz towarzyszących mu mechanizmów mapowania i kontroli.
  • Niezależność architektury. Charakterystyka architektury (język implementacji, interfejs użytkownika i mechanizm upływu czasu) istniejących symulacji była różna. Architektura implikowana przez ALSP musi być dyskretna dla istniejących architektur.

Ramy koncepcyjne

Ramy koncepcyjne to struktura organizacyjna pojęć, która ułatwia tworzenie modeli symulacyjnych. Typowe ramy koncepcyjne obejmują: planowanie zdarzeń, skanowanie działań i interakcje procesów.

Ramy pojęciowe ALSP są oparte na obiektach, gdzie model składa się z obiektów, które charakteryzują się atrybutami, którym przypisane są wartości. Klasy obiektów są zorganizowane hierarchicznie w taki sam sposób, jak w obiektowych językach programowania. ALSP obsługuje konfederację symulacji, które koordynują przy użyciu wspólnego modelu.

Aby zaprojektować mechanizm, który pozwala istniejącym symulacjom na interakcję, możliwe są dwie strategie: (1) zdefiniowanie infrastruktury, która przekłada się między reprezentacjami w każdej symulacji, lub (2) zdefiniowanie wspólnego schematu reprezentacji i wymaganie, aby wszystkie symulacje były mapowane na ten schemat.

Pierwsza strategia wymaga kilku perturbacji w istniejących symulacjach; interakcja jest całkowicie ułatwiona dzięki infrastrukturze połączeń międzysieciowych. Jednak to rozwiązanie nie skaluje się dobrze. Ze względu na podstawowy wymóg skalowalności, projekt ALSP przyjął drugą strategię. ALSP zaleca, aby każda symulacja odwzorowywała schemat reprezentacji konfederacji i jej własny schemat reprezentacji. To odwzorowanie reprezentuje jeden z trzech sposobów, w jaki symulacja musi zostać zmieniona, aby uczestniczyć w konfederacji ALSP. Pozostałe modyfikacje to:

  • Uznanie, że symulacja nie posiada wszystkich obiektów, które postrzega.
  • Modyfikowanie wewnętrznego mechanizmu przesuwania czasu symulacji, tak aby współpracował z innymi symulacjami w ramach konfederacji.

W samodzielnych symulacjach obiekty pojawiają się (i znikają) wraz z upływem czasu symulacji, a rozmieszczenie tych obiektów jest wyłącznie przedmiotem symulacji. Podczas działania w ramach konfederacji relacja obiekt-symulacja jest bardziej skomplikowana.

Właściwość własności obiektu symulacji jest dynamiczna, tj. w trakcie swojego życia obiekt może należeć do więcej niż jednej symulacji. W rzeczywistości dla dowolnej wartości czasu symulacji kilka symulacji może posiadać różne atrybuty danego obiektu. Zgodnie z konwencją symulacja jest właścicielem obiektu, jeśli posiada atrybut „identyfikujący” obiektu. Posiadanie atrybutu obiektu oznacza, że ​​symulacja jest odpowiedzialna za obliczanie i raportowanie zmian wartości atrybutu. Obiekty, które nie są własnością konkretnej symulacji, ale znajdują się w obszarze percepcji symulacji, nazywane są duchami. Duchy to lokalne kopie obiektów należących do innych symulacji.

Kiedy symulacja tworzy obiekt, zgłasza ten fakt konfederacji, aby umożliwić innym symulacjom tworzenie duchów. Podobnie, gdy symulacja usuwa obiekt, zgłasza ten fakt, aby umożliwić usuwanie duchów. Ilekroć symulacja podejmuje akcję między jednym ze swoich obiektów a duchem, symulacja musi zgłosić to konfederacji. W żargonie ALSP jest to interakcja. Te podstawowe koncepcje stanowią podstawę dla pozostałej części prezentacji. Termin model konfederacji opisuje hierarchię obiektów, atrybuty i interakcje obsługiwane przez konfederację.

Oprogramowanie infrastruktury ALSP (AIS)

Obiektowe ramy koncepcyjne przyjęte przez ALSP definiują klasy informacji, które muszą być rozpowszechniane. Oprogramowanie infrastruktury ALSP (AIS) zapewnia dystrybucję danych i koordynację procesów. Głównymi składnikami AIS są wspólny moduł ALSP (ACM) i emulator rozgłaszania ALSP (ABE).

Moduł wspólny ALSP (ACM)

Wspólny moduł ALSP (ACM) zapewnia wspólny interfejs dla wszystkich symulacji i zawiera podstawowe funkcje ALSP. Dla każdej symulacji w konfederacji istnieje jedna instancja ACM. Usługi ACM wymagają zarządzania czasem i obiektami; zawierają:

  • Symulacje współrzędnych dołączania i opuszczania konfederacji.
  • Skoordynuj czas lokalny symulacji z czasem konfederacji.
  • Filtruj wiadomości przychodzące, aby symulacje otrzymywały tylko interesujące wiadomości.
  • Koordynuj własność atrybutów obiektów i zezwalaj na migrację własności.
  • Wymuszaj własność atrybutów, aby symulacje zgłaszały wartości tylko dla atrybutów, których są właścicielami.

Zarządzanie czasem

Przyłączanie się i wychodzenie z konfederacji jest integralną częścią procesu zarządzania czasem. Kiedy symulacja dołącza do konfederacji, wszystkie inne ACM w konfederacji tworzą kolejki komunikatów wejściowych dla nowej symulacji. I odwrotnie, gdy symulacja opuszcza konfederację, inne ACM usuwają kolejki komunikatów wejściowych dla tej symulacji.

Funkcje zarządzania czasem ALSP obsługują symulację zdarzeń dyskretnych przy użyciu mechanizmów asynchronicznych (następne zdarzenie) lub synchronicznych (krokowych w czasie). Mechanizmem wspierającym symulacje następnego zdarzenia jest

  1. Symulacja wysyła komunikat żądania zdarzenia do swojego ACM z parametrem czasu odpowiadającym czasowi T symulacji (czasowi następnego lokalnego zdarzenia).
  2. Jeśli ACM ma komunikaty do symulacji ze znacznikami czasu starszymi lub takimi samymi jak T, ACM wysyła do symulacji najstarszy z nich. Jeśli wszystkie komunikaty mają znaczniki czasu nowsze niż T, ACM wysyła zaliczkę do symulacji, dając jej pozwolenie na przetworzenie lokalnego zdarzenia w czasie T.
  3. Symulacja wysyła wszelkie komunikaty wynikające ze zdarzenia do swojego ACM.
  4. Symulacja jest powtarzana od kroku (1).

Mechanizm wspierający symulację krokową w czasie to:

  1. Symulacja przetwarza wszystkie zdarzenia przez pewien przedział czasu .
  2. Symulacja wysyła żądanie wyprzedzenia do swojego ACM na czas .
  3. , którym następuje przyznanie zaliczki
  4. Symulacja wysyła dowolne komunikaty dotyczące interwału do ACM.
  5. Symulacja jest powtarzana od kroku (1).

AIS zawiera mechanizm unikania zakleszczeń przy użyciu pustych komunikatów. Mechanizm wymaga, aby procesy miały możliwe do wykorzystania wyprzedzające .

Zarządzanie obiektami

ACM administruje bazą danych atrybutów i informacjami o filtrach. Baza danych atrybutów przechowuje obiekty znane symulacji, będące własnością lub zjawy, oraz atrybuty tych obiektów, które obecnie posiada symulacja. W przypadku dowolnej klasy obiektów atrybuty mogą być członkami

  • Utwórz zestaw. Atrybuty minimalnie wymagane do reprezentowania obiektu
  • Zestaw odsetek. Przydatne, ale nie obowiązkowe informacje
  • Zestaw aktualizacji. Wartości atrybutów obiektu zgłoszone przez symulację do konfederacji

Przepływ informacji w sieci można dodatkowo ograniczyć za pomocą filtrów. Filtrowanie zapewnia dyskryminację według (1) klasy obiektu, (2) wartości lub zakresu atrybutu oraz (3) położenia geograficznego. Filtry definiują również interakcje istotne dla symulacji.

Jeśli (aktualizacja spełnia wszystkie kryteria filtrowania) | Jeżeli (obiekt jest znany symulacji) | | Wyślij nowe wartości atrybutów do symulacji | Inaczej (obiekt jest nieznany) | | Jeśli (jest wystarczająco dużo informacji, aby stworzyć ducha) | | | Wyślij wiadomość tworzenia do symulacji | | Inaczej (brak wystarczających informacji) | | | Podane informacje o sklepie | | | Wyślij wniosek do konfederacji o brakujące dane Inaczej (aktualizacja nie spełnia kryteriów filtrowania) | Jeżeli (obiekt jest znany symulacji) | | Wyślij wiadomość usuwania do symulacji | Inaczej | | Odrzuć dane aktualizacji

Informacje o własności i filtrowaniu utrzymywane przez ACM dostarczają informacji niezbędnych do koordynowania przenoszenia własności atrybutów między symulacjami.

Emulator emisji ALSP (ABE)

Emulator emisji ALSP (ABE) ułatwia dystrybucję informacji ALSP. Odbiera wiadomość na jednej ze swoich ścieżek komunikacyjnych i retransmituje wiadomość na wszystkich pozostałych ścieżkach komunikacyjnych. Pozwala to na konfiguracje, w których wszystkie komponenty ALSP są względem siebie lokalne (na tym samym komputerze lub w sieci lokalnej). Pozwala również na konfiguracje, w których zestawy ACM komunikują się z własnym lokalnym ABE z komunikacją między ABE w sieciach rozległych.

Schemat komunikacji

Schemat komunikacji ALSP składa się z (1) modelu komunikacji między komponentami, który definiuje interfejs warstwy transportowej łączącej komponenty ALSP, (2) warstwowego protokołu komunikacji między symulacjami, zarządzania obiektami i zarządzania czasem, (3) schemat filtrowania komunikatów w celu zdefiniowania informacji będących przedmiotem zainteresowania symulacji oraz (4) mechanizm inteligentnej dystrybucji komunikatów.

Model komunikacji między komponentami

AIS wykorzystuje model komunikacji trwałego połączenia, aby zapewnić komunikację między komponentami. Interfejs warstwy transportowej używany do zapewnienia komunikacji między komponentami był podyktowany wymaganiami symulacji i interfejsami warstwy transportowej w systemach operacyjnych obsługujących AIS: lokalne platformy VMS korzystały ze współdzielonych skrzynek pocztowych; nielokalne platformy VMS wykorzystywały Transparent DECnet lub TCP/IP; i platformy typu UNIX korzystają z protokołu TCP/IP.

protokół ALSP

Protokół ALSP opiera się na zestawie zagadnień ortogonalnych, które składają się na przestrzeń problemową ALSP: komunikacji między symulacjami, zarządzaniu obiektami i zarządzaniu czasem. Te problemy są rozwiązywane przez warstwowy protokół, który ma na górze protokół symulacji z podstawowymi protokołami symulacji/ACM, zarządzania obiektami, zarządzania czasem i dystrybucji zdarzeń.

Protokół symulacji

Protokół symulacji jest głównym poziomem protokołu ALSP. Składa się z czterech typów komunikatów:

  • Aktualizacja. Obiekty w ALSP są definiowane przez unikalny numer identyfikacyjny, klasę i zestaw atrybutów powiązanych z c1ass. Gdy symulacja zmienia stan swoich obiektów, wysyła do ACM komunikaty aktualizujące, które zawierają początkowe lub zmienione wartości atrybutów. Następnie ACM przekazuje informacje za pośrednictwem AIS do innych symulacji, które wykazały zainteresowanie.
  • Interakcja. Interakcje między obiektami są identyfikowane według rodzaju. Rodzaje interakcji opisywane są parametrami, podobnie jak obiekty opisywane są atrybutami. Kiedy obiekt symulacji wchodzi w interakcję z obiektem innej symulacji lub obszarem geograficznym, symulacja wysyła komunikat interakcji do ACM w celu dalszego rozpowszechnienia wśród innych zainteresowanych symulacji.
  • Odśwież żądanie. Symulacja może zażądać aktualizacji zestawu wartości atrybutów dla dowolnego obiektu lub klasy obiektów, wysyłając komunikat żądania odświeżenia do konfederacji.
  • Usuwać. Kiedy symulacja powoduje, że jeden z jej obiektów przestaje istnieć, symulacja wysyła komunikat usunięcia, aby poinformować inne symulacje.

Protokół symulacji jest oparty na tekście. Jest zdefiniowany przez gramatykę bezkontekstową LALR (1). Semantyka protokołu jest zależna od konfederacji, gdzie zestaw klas, atrybuty klas, interakcje i parametry interakcji są zmienne. Dlatego składniowa reprezentacja protokołu symulacji może być zdefiniowana bez a priori znajomości semantyki obiektów i interakcji jakiejkolwiek konkretnej konfederacji.

Protokół połączenia symulacji/ACM

Protokół połączenia symulacja/ACM zapewnia usługi zarządzania połączeniem między symulacją a jej ACM oraz metodę wymiany informacji między symulacją a jej ACM. Dystrybucją komunikatów protokołu symulacji sterują dwie usługi: zdarzenia i komunikaty. Komunikaty o zdarzeniach są opatrzone znacznikiem czasu i dostarczane w spójnej czasowo kolejności. Komunikaty dyspozytorskie są dostarczane tak szybko, jak to możliwe, bez względu na czas symulacji. Dodatkowe komunikaty protokołu zapewniają stan połączenia, rejestrację filtra, kontrolę blokady atrybutów, kontrolę składowania konfederacji, kontrolę zasobów obiektów i usługi kontroli czasu.

Protokół zarządzania obiektami

Protokół zarządzania obiektami jest protokołem równorzędnym, który znajduje się poniżej protokołu symulacji i zapewnia usługi zarządzania obiektami. ACM używają go wyłącznie do tworzenia, pozyskiwania, zwalniania i weryfikacji atrybutów obiektów (spójności rozproszonej bazy danych obiektów). Te usługi umożliwiają AIS zarządzanie rozproszoną własnością obiektów.

Rozproszona własność obiektów zakłada, że ​​żadna pojedyncza symulacja nie musi posiadać wszystkich obiektów w konfederacji, ale wiele symulacji wymaga znajomości niektórych obiektów. Symulacja wykorzystuje komunikaty aktualizacji protokołu symulacji do wykrywania obiektów należących do innych symulacji. Jeśli ta symulacja jest zainteresowana obiektami, może je widmować (śledzić ich lokalizację i stan) oraz modelować interakcje z nimi z posiadanych obiektów.

Blokady implementują własność atrybutu. Podstawową funkcją protokołu zarządzania obiektami jest zapewnienie, że symulacja aktualizuje tylko te atrybuty, dla których uzyskała blokadę. Menedżer obiektów w ACM zarządza obiektami i atrybutami obiektów posiadanych i obiektów widmowych znanych ACM. Usługi dostarczane przez protokół symulacji/ACM są wykorzystywane przez symulacje do interakcji z mechanizmem blokowania atrybutów ACM. Koordynacja statusu, żądania, pozyskiwania i zwalniania atrybutów obiektów między ACM wykorzystuje protokół zarządzania obiektami. Każdy atrybut każdego obiektu znany danemu ACM ma status, który przyjmuje jedną z trzech wartości:

  • Zablokowany. Symulacja steruje atrybutem i może aktualizować wartość atrybutu. Symulacja „posiada” atrybut, jeśli ma ten atrybut zablokowany. Symulacja „posiada” obiekt, jeśli ma zablokowany atrybut id.
  • Odblokowany. Żadna symulacja nie kontroluje obecnie tego atrybutu. Każda symulacja prosząca o kontrolę otrzymuje kontrolę.
  • Stracony. Stan kontroli odbywa się gdzie indziej w konfederacji.

Z perspektywy ACM obiekty powstają poprzez proces rejestracji przeprowadzany przez jego symulację lub poprzez odkrywanie obiektów zarejestrowanych przez inne symulacje. Blokady atrybutów stanu początkowego dla obiektów zarejestrowanych i wykrytych są następujące:

  • Rejestracja obiektu umieszcza każdą parę obiekt-atrybut w stanie zablokowanym. Symulacja może opcjonalnie określać atrybuty w stanie odblokowanym.
  • Wykrywanie obiektów dodaje obiekt do bazy danych obiektów jako widmowy obiekt. Wszystkie atrybuty tego obiektu są oznaczone statusem zniknął.

Protokół zarządzania czasem

Protokół zarządzania czasem jest również protokołem równorzędnym, który znajduje się poniżej protokołu symulacji. Zapewnia usługi zarządzania czasem w celu synchronizacji czasu symulacji między ACM. Protokół zapewnia usługi dla rozproszonej koordynacji wejścia symulacji do konfederacji, postępu czasowego i zapisów konfederacji.

Usługi dołączania/rezygnacji oraz mechanizmy synchronizacji czasu zostały opisane w punkcie wcześniej. Mechanizm składowania zapewnia odporność na błędy. Koordynacja jest wymagana do stworzenia spójnej migawki wszystkich ACM, tłumaczy i symulacji dla określonej wartości czasu symulacji.

Filtrowanie wiadomości

ACM wykorzystuje filtrowanie komunikatów symulacyjnych do oceny treści komunikatu otrzymanego od konfederacji. ACM dostarcza do swojej symulacji komunikaty, które są interesujące, spełnia kryteria filtrowania i odrzuca te, które nie są interesujące. ACM filtruje dwa typy komunikatów: komunikaty aktualizacyjne i komunikaty interakcyjne.

Zaktualizuj komunikaty. ACM ocenia komunikaty aktualizacji na podstawie kryteriów filtrowania komunikatów aktualizacji symulacji, które zapewnia symulacja. Jak omówiono wcześniej, kiedy ACM odbiera komunikat o aktualizacji, istnieją cztery możliwe wyniki: (1) ACM odrzuca komunikat, (2) ACM wysyła komunikat o utworzeniu symulacji, (3) ACM wysyła do symulacji komunikat o aktualizacji lub (4) ACM wysyła symulacji komunikat usunięcia.

Komunikaty interakcji. ACM może odrzucić komunikaty interakcji z powodu parametru rodzaju. Parametr rodzaj ma hierarchiczną strukturę podobną do struktury klas obiektów. Symulacja informuje ACM o rodzajach interakcji, które powinny przejść lub nie przejść przez filtr interakcji.

Dystrybucja wiadomości

Aby zminimalizować ruch komunikatów między komponentami w konfederacji ALSP, AIS wykorzystuje formę inteligentnego kierowania komunikatów, która wykorzystuje protokół dystrybucji zdarzeń (EDP). EDP ​​umożliwia ACM informowanie innych komponentów AIS o aktualizacjach i filtrach interakcji zarejestrowanych przez ich symulacje. W przypadku komunikatów aktualizacyjnych dystrybucja tych informacji pozwala ACM na dystrybucję tylko danych o klasach (i atrybutach klas), które są przedmiotem zainteresowania konfederacji. ABE wykorzystuje te informacje również do wysyłania tylko tych informacji, które są interesujące dla obsługiwanych komponentów. W przypadku komunikatów interakcji proces jest podobny, z tą różnicą, że parametr rodzaj w komunikacie interakcji określa miejsce wysłania komunikatu.

Dalsza lektura

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Aggregate_Level_Simulation_Protocol&oldid=1058676863 ”