Üst Düzey Mimari - High Level Architecture

Bu makale, dağıtılmış simülasyon için IEEE standardı ile ilgilidir. Diğer kullanımlar için, bkz. Yüksek ve düşük seviye .

Yüksek Düzey Mimari ( HLA ) (federating) birkaç simülasyonları birleştirerek daha büyük bir amaç için bir simülasyon oluştururken kullanılan dağıtılmış simülasyon için bir standarttır. Standart, 90'lı yıllarda ABD Savunma Bakanlığı önderliğinde geliştirildi ve daha sonra açık uluslararası bir IEEE standardı haline getirildi. STANAG 4603 aracılığıyla NATO içinde önerilen bir standarttır. Günümüzde HLA, savunma ve güvenlik ve sivil uygulamalar dahil olmak üzere birçok alanda kullanılmaktadır.

HLA'nın amacı, birlikte çalışabilirliği ve yeniden kullanımı sağlamaktır. HLA'nın temel özellikleri şunlardır:

  • İşletim sistemlerinden ve uygulama dillerinden bağımsız olarak yerel veya yaygın olarak dağıtılmış farklı bilgisayarlarda çalışan simülasyonları tek bir Federasyona bağlama yeteneği.
  • Farklı uygulama etki alanları için bilgi alışverişi veri modelleri, Federasyon Nesne Modelleri (FOM'ler) belirleme ve kullanma becerisi.
  • FOM'a dayalı bir yayınla-abone ol mekanizması kullanarak ve ek filtreleme seçenekleriyle bilgi alışverişi için hizmetler.
  • Mantıksal (simülasyon) zaman ve zaman damgalı veri alışverişini koordine etmek için hizmetler.
  • Bir Federasyonun durumunu denetlemek ve ayarlamak için yönetim hizmetleri.

HLA, örneğin havacılık ve savunma gibi farklı topluluklarda standartlaştırılmış ve genişletilebilir FOM'lar geliştirmenin temelini oluşturur.

Mimari aşağıdaki bileşenleri belirtir.

HLA federasyonunun bileşenleri
  • Bir çalışma zamanı Altyapı farklı programlama dilleri aracılığıyla hizmetlerin standart bir kümesi sağlar (RTI). Bu hizmetler bilgi alışverişi, senkronizasyon ve federasyon yönetimini içerir.
  • Federates Rti hizmetlerini kullanarak bireysel simülasyon sistemlerdir.
  • Veri alışverişinde kullanılan Nesne Sınıflarını ve Etkileşim Sınıflarını belirten bir Federasyon Nesne Modeli (FOM). FOM, herhangi bir etki alanı için bilgileri tanımlayabilir.

Yukarıdaki bileşenler birlikte bir Federasyon oluşturur .

HLA standardı üç bölümden oluşur:

  1. Bileşenlerin veya tüm federasyonun uyması gereken on mimari kuralı belirten IEEE Std 1516-2010 Çerçeve ve Kurallar .
  2. RTI tarafından sağlanacak hizmetleri belirten IEEE Std 1516.1-2010 Federate Interface Spesifikasyonu . Hizmetler, Web Hizmetlerinin yanı sıra C++ ve Java API'leri olarak sağlanmaktadır.
  3. FOM gibi HLA nesne modellerinin kullanacağı formatı belirten IEEE Std 1516.2-2010 Nesne Modeli Şablon Spesifikasyonu .

Tarihçe ve sürümler

HLA, 1990'ların başında , ABD Savunma Bakanlığı bünyesindeki Savunma Araştırma ve Mühendisliği Direktörü Dr. Anita K. Jones'un Savunma Modelleme ve Simülasyon Ofisi'ne (DMSO) “savunma modellerinin birlikte çalışabilirliğini ve yeniden kullanılabilirliğini sağlama” görevini vermesiyle başlatıldı. ve simülasyonlar”. 1995 yılında DMSO, modelleme ve simülasyon için bir vizyon formüle etti ve Üst Düzey Mimariyi içeren bir modelleme ve simülasyon ana planı oluşturdu.

M&S birlikte çalışabilirliği için iki protokol zaten mevcuttu: Sabit bir nesne modeliyle gerçek zamanlı platform düzeyinde simülasyona odaklanan Dağıtılmış Etkileşimli Simülasyon (DIS) ve zaman yönetimi, sahiplik yönetimi ve esnek ile toplamın simülasyonuna odaklanan Toplama Düzeyinde Simülasyon Protokolü (ALSP) Konfederasyon modelleri olarak adlandırılan nesne modelleri. HLA'nın amacı, tüm ABD Savunma Bakanlığı bileşenlerinin simülasyon birlikte çalışabilirlik gereksinimlerini karşılayacak tek bir birleşik standart sağlamaktı.

HLA'nın geliştirilmesi dört prototip federasyona dayanıyordu: Platform Prototip Federasyonu, Ortak Eğitim Protofederasyonu, Analiz Protofederasyonu ve Mühendislik Prototip Federasyonu. HLA spesifikasyonu, HLA 1.3 nihayet yayınlanana kadar prototiplendi ve geliştirildi. Savunma topluluğu dışında kullanımı kolaylaştırmak için HLA, Simülasyon Birlikte Çalışabilirlik Standartları Organizasyonu (SISO) tarafından sürdürülen bir IEEE standardına dönüştürüldü . DIS kullanıcıları için geçişi kolaylaştırmak için, DIS'in sabit nesne modeline karşılık gelen bir Federasyon Nesne Modeli de Gerçek Zamanlı Platform Referans FOM ( RPR FOM ) olarak geliştirilmiştir.

Aşağıdaki HLA sürümleri mevcuttur:

HLA 1.3

HLA 1.3, Mart 1998'de DMSO tarafından yayınlandı. Bu oluşmaktadır:

  • ABD Savunma Bakanlığı, Kurallar Sürüm 1.3
  • ABD Savunma Bakanlığı, Yüksek Düzey Mimari Arayüz Spesifikasyonu Sürüm 1.3
  • ABD Savunma Bakanlığı, Üst Düzey Mimari Nesne Modeli Şablonu Sürüm 1.3

ABD Savunma Bakanlığı ayrıca HLA 1.3 için yorumlar yayınladı:

  • ABD Savunma Bakanlığı, Üst Düzey Mimari Arayüz Spesifikasyonu Sürüm 1.3, Sürüm 3'ün Yorumları

HLA 1516-2000

HLA IEEE 1516-2000, 2000 yılında IEEE tarafından yayınlandı. Bu oluşmaktadır:

  • IEEE Std 1516–2000 – Modelleme ve Simülasyon Standardı Yüksek Düzey Mimari – Çerçeve ve Kurallar
  • IEEE Std 1516.1–2000 – Modelleme ve Simülasyon Standardı Yüksek Düzey Mimari – Birleşik Arabirim Spesifikasyonu
  • IEEE 1516.1–2000 Hata (2003-ekim-16)
  • IEEE 1516.2-2000 – Modelleme ve Simülasyon Standardı Yüksek Düzey Mimari – Nesne Modeli Şablonu (OMT) Spesifikasyonu

IEEE 1516-2000'deki büyük iyileştirmeler, ayrıntılı veri türü özelliklerine sahip XML tabanlı bir FOM'un yanı sıra geliştirilmiş bir DDM tasarımını içeriyordu.

IEEE 1516-2000 standardı ayrıca önerilen bir geliştirme süreci ve önerilen bir VV&A süreci ile tamamlanmıştır:

  • IEEE 1516.3-2003 – Yüksek Düzeyli Mimari Federasyonu Geliştirme ve Yürütme Süreci (FEDEP) için Önerilen Uygulama. Bu standart daha sonra IEEE Std 1730-2010 Dağıtılmış Simülasyon Mühendisliği ve Yürütme Süreci ( DSEEP ) haline gelecekti.
  • IEEE 1516.4-2007 – Bir Federasyonun Doğrulanması, Doğrulanması ve Akreditasyonu için Önerilen Uygulama ve Üst Düzey Mimari Federasyon Geliştirme ve Yürütme Sürecinin Yerleşimi

1516-2000 standardının, her RTI uygulaması için biraz farklı olan API'lere sahip olduğu çok geçmeden bulundu. SISO, alternatif, dinamik bağlantı uyumlu (DLC) C++ ve Java API'lerine sahip bir standart üretti:

  • SISO-STD-004.1-2004: HLA Arabirim Spesifikasyonu için Dinamik Bağlantı Uyumlu HLA API Standardı (IEEE 1516.1 Sürümü) için Standart
  • SISO-STD-004-2004: HLA Arayüzü Spesifikasyonu (v1.3) için Dinamik Bağlantı Uyumlu HLA API Standardı için Standart

DLC API'leri daha sonra ana standartla birleştirildi.

HLA 1516-2010 (HLA Evrimleşmiş)

IEEE 1516-2010 standardı, Ağustos 2010'da IEEE tarafından yayınlandı ve yaygın olarak HLA Evolved olarak bilinir. Bu oluşmaktadır:

  • IEEE 1516–2010 – Modelleme ve Simülasyon Standardı Yüksek Düzey Mimari – Çerçeve ve Kurallar
  • IEEE 1516.1–2010 – Modelleme ve Simülasyon Standardı Yüksek Düzey Mimari – Federal Arayüz Spesifikasyonu
  • IEEE 1516.2-2010 – Modelleme ve Simülasyon Standardı Yüksek Düzey Mimari – Nesne Modeli Şablonu (OMT) Spesifikasyonu

IEEE 1516-2010'daki önemli iyileştirmeler arasında Modüler FOM'lar, DLC API'lerinin C++ ve Java'ya dahil edilmesi, bir Web Hizmetleri API'si ve Hata Toleransı yer alır.

HLA'nın bu sürümünün XML Şemaları, C++, Java ve WSDL API'leri gibi makine tarafından okunabilen kısımlarının yanı sıra FOM/SOM örnekleri IEEE web sitesinin IEEE 1516 indirme alanından indirilebilir . Tam standart metinleri SISO üyelerine ücretsiz olarak sunulur veya IEEE mağazasından satın alınabilir .

HLA 1516-20XX (HLA 4)

HLA'nın yeni bir versiyonunun geliştirilmesine SISO tarafından Ocak 2016'da başlandı ve şu anda devam ediyor.

Teknik Genel Bakış

HLA standardı üç bölümden oluşur:

  • Federasyonların veya tüm federasyonun uyması gereken on mimari kuralı belirten Çerçeve ve Kurallar .
  • RTI tarafından sağlanacak hizmetleri belirten Federasyon Arayüz Spesifikasyonu . Hizmetler, Web Hizmetlerinin yanı sıra C++ ve Java API'leri olarak sağlanmaktadır.
  • FOM gibi HLA nesne modellerinin kullanacağı formatı belirten Nesne Modeli Şablon Spesifikasyonu .

Ortak HLA terminolojisi

  • Çalışma Zamanı Altyapısı (RTI) : HLA Federate Interface Spesifikasyonunda belirtildiği gibi standartlaştırılmış bir dizi hizmet sağlayan yazılım. Yedi hizmet grubu vardır.
  • Federate : RTI'ye bağlanan bir simülasyon, bir araç veya canlı sistemlere bir arayüz gibi bir sistem. Araç örnekleri, veri kaydediciler ve yönetim araçlarıdır. Bir federasyon, veri alışverişi yapmak ve diğer federasyonlarla eşitlemek için RTI hizmetlerini kullanır.
  • Federasyon : Ortak bir FOM ile aynı RTI'ye bağlanan bir federasyonlar grubu.
  • Federasyon Yürütme : Bir grup federasyonun aynı RTI ve FOM'u kullanarak belirli bir amaç doğrultusunda bir federasyon içinde birlikte yürüttüğü bir oturum.
  • Federasyon Nesne Modeli (FOM) : Bir federasyonda bilgi alışverişi için kullanılan nesne sınıflarını, etkileşim sınıflarını, veri türlerini ve ek verileri belirten bir belge. Bir FOM, HLA Nesne Modeli Şablonu ve ilgili XML Şeması biçimini izleyen bir XML dosyasıdır. Farklı uygulama etki alanları için veri alışverişi için farklı FOM'lar kullanılır. FOM geliştirme için bir başlangıç ​​noktası olarak yaygın olarak kullanılan, referans FOM'lar olarak adlandırılan standartlaştırılmış FOM'lar vardır. Bir FOM, FOM modülleri kullanılarak modüler bir şekilde geliştirilebilir ve genişletilebilir.
  • Simulation Object Model (SOM) : Belirli bir simülasyonun bir federasyonda yayınladığı ve/veya abone olduğu nesne sınıflarını, etkileşim sınıflarını, veri türlerini ve ek verileri belirten bir belge. SOM aynı zamanda HLA Nesne Modeli Şablonu ve ilgili XML Şeması biçimini izleyen bir XML dosyasıdır. SOM'lar ayrıca SOM modülleri kullanılarak modüler bir şekilde geliştirilebilir ve genişletilebilir.
  • Nesne : Nesneler, belirli bir süre boyunca kalıcı olan ve güncellenebilen öznitelikleri olan verileri temsil etmek için kullanılır. Bir Nesne Sınıfı kullanılarak FOM/SOM'da tanımlanırlar.
  • Etkileşim : Etkileşim, anlık olayları parametrelerle temsil etmek için kullanılır. Gönderilen bir etkileşim güncellenemez (nesne sınıflarının aksine). Bir Etkileşim Sınıfı kullanılarak FOM/SOM'da tanımlanırlar.
  • Veri türleri : Öznitelik ve parametre verilerinin gösterimi ve yorumlanması, HLA Veri Türleri kullanılarak FOM/SOM'da belirtilir.
  • Yayınla : Bir nesne sınıfını bir dizi öznitelikle yayınlayan bir federasyon, o nesne sınıfının örneklerini kaydedebilir ve silebilir ve öznitelik değerlerini güncelleyebilir. Bir etkileşim sınıfı yayınlayan bir federasyon, ilişkili parametre değerleriyle birlikte o etkileşim sınıfının etkileşimlerini gönderebilir.
  • Abone Ol : Bir nesne sınıfına bir dizi öznitelikle abone olan bir federe, o nesne sınıfının örneklerinin kayıtlarını ve silinmesini keşfedecek ve abone olunan özniteliklerin güncellemelerini alacaktır. Bir etkileşim sınıfına abone olan bir federasyon, ilişkili parametre değerleriyle birlikte o etkileşim sınıfının etkileşimlerini alır.

Arayüz özellikleri

RTI hizmetleri, HLA Arayüz Spesifikasyonunda tanımlanmıştır. Yedi hizmet grubuna ayrılırlar. Bu hizmetlere ek olarak, Yönetim Nesnesi Modeli (MOM), federasyonun durumunu programlı olarak incelemeyi ve ayarlamayı mümkün kılan hizmetler sunar.

Çoğu RTI, yürütülebilir bir Merkezi RTI Bileşeninden (CRC) ve federasyonlar tarafından kullanılan kitaplıklar olan Yerel RTI Bileşenlerinden (LRC'ler) oluşur. Hizmetler, bir C++ veya Java API aracılığıyla ve ayrıca Web hizmetleri kullanılarak sağlanır. C++ ve Java API'lerinde hizmetler, RTI Ambassador sınıfının bir örneğine yapılan çağrılar kullanılarak çağrılır. RTI, Federate Ambassador sınıfının bir örneğine yapılan çağrılar kullanılarak teslim edilen geri aramaları kullanarak bilgileri bir federasyona iletir. WSDL kullanılarak tanımlanan Web Hizmetleri API'sinde, Web Hizmetleri istekleri ve yanıtları kullanılarak federasyon tarafından çağrılar yapılır ve geri çağrılar getirilir.

Aşağıdaki hizmet grubu açıklamaları, temel hizmetlere odaklanmaktadır. İstisnalar ve tavsiyeler dahil değildir.

Federasyon Yönetim Hizmetleri

HLA Arayüzü Belirtiminin 4. bölümünde açıklanan Federasyon Yönetimi hizmetlerinin amacı, Federasyon Yürütmelerinin yanı sıra Eşitleme Noktaları ve Kaydet/Geri Yükle gibi federasyon çapındaki işlemleri yönetmektir.

Bir Federasyon Yönetimi hizmetleri grubu, RTI ile bağlantıyı, federasyon yürütmesini ve birleştirilmiş federasyonlar grubunu yönetir. Anahtar hizmetler şunlardır:

  • RTI'ye Bağlanma ve Bağlantıyı Kesme
  • Federasyon yürütmesini oluşturmak ve yok etmek için kullanılan CreateFederationExecution ve DestroyFederationExecution
  • Bir federasyon tarafından bir federasyon yürütmesine katılmak ve istifa etmek için kullanılan JoinFederationExecution ve ResignFederationExecution.
  • RTI tarafından bir federasyonu bir hata nedeniyle federasyon yürütmesiyle bağlantısını kaybettiğini bildirmek için kullanılan ConnectionLost
  • Bir RTI için kullanılabilir federasyon yürütmelerinin listesini almak için kullanılan ListFederationExecutions

Başka bir hizmet grubu, senkronizasyon noktalarıyla ilgilidir. Bunlar, yürütme devam etmeden önce bir senaryo başlatmak gibi bir işlemi tamamlamak için tüm veya seçilen federasyonların gerekli olduğu federasyon çapında olaylardır. Anahtar hizmetler şunlardır:

  • Bir senkronizasyon noktasını kaydetmek için kullanılan RegisterFederationSynchronizationPoint
  • RTI tarafından bir senkronizasyon noktasının kaydedildiğini federasyonlara bildirmek için kullanılan AnnounceSynchronizationPoint
  • Bir federasyon tarafından bir senkronizasyon noktasına ulaştığını belirtmek için kullanılan SynchronizationPointAchieved
  • RTI tarafından federasyonların federasyonun senkronize olduğunu bildirmek için kullanılan FederationSynchronized, yani tüm federasyonlar senkronizasyon noktasına ulaştı.

Yine başka bir hizmet grubu, bir federasyon yürütmesini kaydetme ve geri yükleme ile ilgilidir. Bir kaydetme işlemi, hem RTI'nin hem de her federasyonun kendi iç durumlarını kaydetmesini gerektirir. Bir geri yükleme işlemi, hem RTI'nin hem de her federasyonun kendi iç durumlarını geri yüklemesini gerektirir. Anahtar hizmetler şunlardır:

Kaydetmek:

  • Bir federasyonun kaydedilmesini başlatmak için kullanılan RequestFederationSave
  • RTI tarafından federasyonlara durumunu kurtarmaya başlamalarını bildirmek için kullanılan InitiateFederateSave
  • Bir federasyon tarafından durumunu kaydetmeyi tamamladığında çağrılacak olan FederateSaveComplete.
  • RTI tarafından federasyonun kaydedildiğini federasyonlara bildirmek için kullanılan FederationSaved

Onarmak:

  • Bir federasyonun geri yüklenmesini başlatmak için kullanılan RequestFederationRestore
  • RTI tarafından federasyonlara durumunu geri yüklemeye başlamalarını bildirmek için kullanılan InitiateFederateRestore
  • Federasyon tarafından durumunu geri yüklemeyi tamamladığında çağrılacak olan FederateRestoreComplete.
  • Federasyonların geri yüklendiğini federasyonlara bildirmek için RTI tarafından kullanılan FederationRestored

Beyanname Yönetim Hizmetleri

HLA Arayüz Spesifikasyonunun 5. bölümünde açıklanan Beyan Yönetimi hizmetlerinin amacı, federasyonların FOM'daki nesne ve etkileşim sınıflarına dayalı olarak hangi bilgileri yayınlamak (göndermek) ve abone olmak (almak) istediklerini beyan etmelerini sağlamaktır. RTI, bu bilgileri güncellemeleri ve etkileşimleri abone olan federasyonlara yönlendirmek için kullanır. Bir nesne sınıfı için, belirli bir öznitelik kümesi için yayınlama ve abone olma gerçekleştirilir. Etkileşim sınıfları için, tüm parametreler dahil tüm etkileşim yayınlanır ve abone olunur. Anahtar hizmetler şunlardır:

  • Belirli bir nesne sınıfı için bir dizi öznitelik yayınlamak için kullanılan PublishObjectClassAttributes.
  • Belirli bir nesne sınıfı için bir dizi özniteliğe abone olmak için kullanılanSubscribeObjectClassAttributes.
  • Tüm parametreleri içeren bir etkileşim sınıfını yayınlamak için kullanılan PublishInteractionClass
  • Tüm parametreleri içeren bir etkileşim sınıfına abone olmak için kullanılanSubscribeInteractionClass

Nesne Yönetim Hizmetleri

HLA Arayüz Spesifikasyonunun 6. bölümünde açıklanan Nesne Yönetimi hizmetlerinin amacı, federasyonların nesne örnekleri hakkında bilgi paylaşmasına ve etkileşim alışverişinde bulunmasına olanak sağlamaktır.

Nesne örneği adları rezerve edilebilir veya otomatik olarak oluşturulabilir. Federasyonlar, daha sonra federasyonlara abone olarak keşfedilen, belirtilen nesne sınıflarının nesne örneklerini kaydedebilir. Bu nesne örneklerinin öznitelikleri güncellenebilir. Bu güncellemeler, abone olan federasyonlara yansıtılacaktır. Etkileşimler gönderilebilir. Bu etkileşimler, abone olan federasyonlara iletilecektir. Anahtar hizmetler şunlardır:

nesneler:

  • Bir nesne örneği için kullanılacak bir ad ayırmak için kullanılan ReserveObjectInstanceName
  • Belirli bir nesne sınıfının nesne örneğini, ayrılmış bir adla veya otomatik olarak oluşturulan bir adla kaydetmek için kullanılan RegisterObjectInstance.
  • RTI tarafından belirli bir nesne sınıfına abone olan federasyonlara yeni bir nesne örneğinin kaydedildiğini bildirmek için kullanılan DiscoverObjectInstance.
  • Bir nesne örneğini silmek için kullanılan DeleteObjectInstance
  • Bir nesne örneğinin kaldırıldığını federasyonlara bildirmek için RTI tarafından kullanılan RemoveObjectInstances

Öznitellikler:

  • Bir nesne örneği için güncellenmiş öznitelik değerleri sağlamak için kullanılan UpdateAttributeValues
  • RTI tarafından güncellenmiş değerlerin belirli özniteliklerine abone olan federasyonları bilgilendirmek için kullanılan ReflectAttributeValues.

Etkileşimler:

  • Parametre değerleri de dahil olmak üzere belirli bir etkileşim sınıfının etkileşimini göndermek için kullanılan SendInteraction.
  • Belirli bir etkileşim sınıfına abone olan federasyonlara parametre değerleri de dahil olmak üzere bir etkileşim sağlamak için RTI tarafından kullanılan ReceiveInteraction

Mülkiyet Yönetim Hizmetleri

HLA Arayüz Spesifikasyonunun 7. bölümünde açıklanan Sahiplik Yönetimi hizmetlerinin amacı, bir nesne örneğinin hangi yönünü simüle eden hangi federasyonu dinamik olarak yönetmektir. HLA'da, yalnızca bir federasyonun belirli bir nesne örneğinin belirli bir özniteliğini güncellemesine izin verilir. Bu federasyon, özelliğin sahibi olarak kabul edilir. Yeni bir nesne örneğini kaydeden bir federasyon, yayınladığı tüm özniteliklerin otomatik olarak sahibi olacaktır. Bazı durumlarda, bir nesne örneğinin nitelikleri sahipsiz hale gelebilir, yani herhangi bir federasyona ait olmayabilir.

Sahiplik yönetimi, bir federasyonun Niteliği elden çıkarmasını ve başka bir federasyonun Niteliği edinmesini içerebilen, çalışma zamanında bir veya daha fazla özelliğin sahipliğini aktarmak için hizmetler sağlar. İki ana model vardır: devralan federasyon tarafından başlatılan “çekme” ve elden çıkaran federasyon tarafından başlatılan “itme”.

"Çekme" sahipliğini başlatmak için temel hizmetler şunlardır:

  • AttributeOwnershipAcquisitionIfAvailable, sahip olunmayan özniteliklerin sahipliğini almak isteyen bir federasyon tarafından kullanılır.
  • Potansiyel olarak sahip olunan bir özniteliğin sahipliğini talep etmek isteyen bir federasyon tarafından kullanılan AttributeOwnershipAcquisition

“Push” sahipliğini başlatmak için temel hizmetler şunlardır:

  • AttributeOwnershipDivestitureIfWanted, nitelikleri elden çıkarmak isteyen bir federasyon tarafından, yalnızca bu niteliklerin sahipliğini almak için bekleyen başka bir federasyon varsa kullanılır.
  • NegotiatedAttributeOwnershipDivestiture, benzer ancak aynı zamanda RTI'nin yeni bir sahip bulmaya çalışmasına neden olabilir.
  • Yeni sahip bulunmasa bile mülkiyetten vazgeçmek isteyen bir federasyon tarafından kullanılan UnconditionalAttributeOwnershipDivestiture.

Tüm nesne örnekleri, HLAPrivilegeToDeleteObject adlı önceden tanımlanmış bir özniteliğe sahiptir. Yalnızca bir nesne örneği için bu özniteliğin sahibinin nesne örneğini silmesine izin verilir. Bu özniteliğin sahipliği, yukarıdaki işlemler kullanılarak çalışma zamanında aktarılabilir.

Zaman Yönetimi Hizmetleri

Bir HLA federasyonundaki bilgi alışverişi, HLA Zaman Yönetimi etkinleştirilmedikçe, mesajların anında (Sipariş Alma, RO) teslimi ile gerçek zamanlı olarak gerçekleşir. HLA Arayüzü Spesifikasyonu'nun 8. bölümünde açıklanan HLA Zaman Yönetiminin amacı, federasyon ne yaparsa yapsın, Zaman Damgası Sırasında (TSO) nedenselliği ve zaman damgalı mesajların (güncellemeler ve etkileşimler) doğru ve tutarlı bir şekilde değişimini garanti etmektir. gerçek zamanlı, gerçek zamanlıdan daha hızlı, gerçek zamanlıdan daha yavaş veya mümkün olduğunca hızlı.

HLA Zaman Yönetimindeki bazı önemli kavramlar şunlardır:

Mantıksal zaman : HLA'da sıfırdan başlayan bir zaman ekseni. Zaman Yönetimi zaman damgaları ve işlemleri için mantıksal zaman kullanılır. Mantıksal zaman ekseni, federasyonun senaryo zamanına eşlenebilir. Böyle bir eşlemeye bir örnek, sıfırın 1-Ocak-1066'nın 8:00 senaryo zamanını temsil etmesine ve bir artışın senaryonun bir saniyesini temsil etmesine izin vermektir.

Lookahead : Bir federasyonun mesaj üreteceği gelecekte en düşük zamanı belirten bir zaman aralığı. Sabit bir zaman adımına sahip bir federasyon için bu genellikle zaman adımının uzunluğudur.

Verildi : Bir federasyona, o zamana kadar tüm zaman damgalı iletiler teslim edildiğinde, RTI tarafından belirli bir mantıksal zamana verilir (ilerleme izni verilir). Federasyon daha sonra gelecekte bir zaman damgası olan mesajları güvenli bir şekilde hesaplamaya başlayabilir. Bu zaman damgası, verilen zamandan ve federasyonların ileriye baktığından daha erken olamaz.

İlerleme : Bir federasyon, verilen süre artı ileriye dönük veri üretmeyi bitirdiğinde, daha sonraki bir zamana ilerletmeyi talep edebilir, bu aynı zamanda istenen zamandan daha az bir zaman damgası ile daha fazla mesaj üretmemeyi taahhüt ettiği anlamına gelir. ileriye dönük. Federasyon şimdi ilerleme durumunda.

Zaman Düzenleyici : Zaman damgalı olaylar gönderen bir federasyon, diğer federasyonlar tarafından zaman ilerlemesi bu şekilde düzenlenebileceğinden Zaman Düzenleyici olarak kabul edilir.

Zaman Kısıtlı : Zaman yönetimli olayları alan bir federasyon, zaman damgalı mesajların alınması, zaman ilerlemesini kısıtladığı için Zaman Kısıtlı olarak kabul edilir.

HLA Zaman Yönetiminin temel ilkeleri şunlardır:

  • Her federasyon, mesajlara (güncellemeler ve etkileşimler) gönderildiklerinde, mesajın hangi senaryo süresi için geçerli olduğunu belirten bir zaman damgası atar.
  • Federasyonlar, zamanlarını ilerletmek için RTI'den izin isterler.
  • RTI, mesajların teslimini yönetir ve federasyonlara zaman avansı verir, böylece mesajlar Zaman Damgası Sırasında teslim edilir ve federasyonlar geçmişlerinde bir zaman damgası olan mesajlar almazlar.

Verilen ve ilerleyen Lookahead örneği:

  1. Bir federasyon, 10'luk sabit bir zaman adımı kullanır ve Öngörüsü 10'dur.
  2. Federasyon, RTI tarafından mantıksal süre 50'ye verilir. Böylece RTI, zaman adımı 50'den küçük veya eşit olan tüm mesajların federasyona teslim edildiğini garanti eder.
  3. Federasyon artık, verilen süre artı Lookahead, yani 60 için mesajları doğru bir şekilde hesaplamak ve göndermek için gerekli tüm verilere sahiptir.
  4. Federasyon, 60 zaman damgalı tüm mesajları gönderdiğinde, 60 zamanına kadar ilerlemek ister. Böylece, zaman damgası 70'ten az olan mesajları göndermemeyi taahhüt eder.
  5. RTI, zaman damgası 60'a eşit veya daha küçük olan tüm mesajları federasyona iletir. Daha sonra federasyona 60 süre verir.
  6. Vesaire.

Federasyondaki en az bir federasyon ilerleme hızı uygularsa, yani zaman ilerleme isteklerini gerçek zamanlı bir saatle ilişkilendirirse, federasyon gerçek zamanlı veya ölçeklenmiş gerçek zamanlı olarak çalışabilir. Hızlanma olmadan, örneğin Monte Carlo simülasyonunda kullanılan federasyon mümkün olduğu kadar hızlı koşacaktır.

Anahtar hizmetler şunları içerir:

  • Bir federasyon için tez modlarını etkinleştiren EnableTimeConstrained ve EnableTimeRegulated
  • TimeAdvanceRequest, bir federasyonun belirli bir mantıksal zamana ilerletilmesini talep eder.
  • TimeAdvancedGrant, RTI'nin bir federasyonu belirli bir mantıksal zamana verildiği konusunda bilgilendirdiği zaman.
  • Hem bir federasyon verilmiş hem de ilerleme durumundayken Alma Emri iletilerinin teslim edilmesini sağlayan EnableAsynchronousDelivery.

Olaya dayalı simülasyon için, bir federasyonun aşağıdaki hizmeti kullanarak bir sonraki olaya ilerleme talebinde bulunması da mümkündür:

  • NextMessageRequest, bir federasyona teslim edilecek sonraki mesajın zaman damgasına veya belirli bir mantıksal zamana (hangisi daha düşük zaman damgasına sahipse) ilerlemeyi talep eder.

Bir diğer önemli kavram ise Mevcut En Büyük Mantıksal Zaman'dır (GALT). Her bir federasyona verilebilecek en büyük süre, diğer federasyonlara verilen süreye ve geleceklerine bağlıdır. Bir federasyon için GALT, diğer federasyonların verilmesini beklemek zorunda kalmadan bir federasyonun ne kadar verilebileceğini belirtir. Bu, zaman yönetimli bir federasyona geç katılan bir federasyon için özellikle ilginçtir.

GALT için temel hizmetler şunlardır:

  • Çağıran federasyon için GALT değerini döndüren QueryGALT.

Daha gelişmiş hizmetler şunları içerir:

  • FlushQueueRequest sayesinde bir federasyon, zaman damgası ne kadar ileride olursa olsun sıraya alınmış, zaman damgalı tüm iletilerin teslim edilmesini isteyebilir.
  • Bir federasyonun önceden gönderilmiş bir mesajın geri çekilmesini talep edebileceği geri çekme. Bu iyimser simülasyonda kullanışlıdır.

Veri Dağıtımı Yönetim Hizmetleri (DDM)

HLA Arayüz Spesifikasyonunun 9. bölümünde açıklanan DDM'nin amacı, abone olunan verilerin sınıf ve öznitelik aboneliklerinin ötesinde ek filtreleme gerçekleştirerek federasyonların ölçeklenebilirliğini artırmaktır. Filtreleme, sürekli değerlere (enlem ve boylam gibi) veya ayrı değerlere (araba markası gibi) dayalı olabilir.

DDM'nin temel kavramları şunlardır:

Boyut : 0 ile başlayan ve bir üst sınır n ile biten değerlerle filtreleme için kullanılan adlandırılmış bir aralık (0..n). Simülasyon alanındaki veriler bir veya daha fazla boyuta eşlenir. Örneğin, coğrafi filtreleme için boyutlar LatitudeDimension ve LongitudeDimension olabilir. Araba markasına dayalı filtreleme için bir boyut CarBrandDimension olabilir.

Normalleştirme işlevi : bir boyutta kullanılacak girdi değerlerini tamsayı değerlere eşleyen bir işlev. Bir örnek, LatitudeDimension için bir normalleştirme işlevinin -90.0 ile +90.0 arasında değişen bir enlem değerini 0.179 aralığında bir tam sayıya eşleyebilmesidir. CarBrandDimension için bir normalleştirme işlevi, Kia, Ford, BMW ve Peugeot otomobil markalarını 0..3 aralığında bir tam sayıya eşleyebilir.

Aralık : bir boyut üzerinde bir alt sınır (dahil) ve bir üst sınır (hariç) ile belirtilen bir aralık.

Bölge : her biri belirli bir boyutla ilgili olan bir dizi aralık. Yukarıdaki örnekte, bir bölge, LongitudeDimension için LatitudeDimension (55..65) için (3..5) ve CarBrandDimension için (0..1) aralığından oluşabilir. Çalışma zamanında Bölge Gerçekleştirmeleri (nesneler), bölgeleri temsil etmek için başlatılır. Bir bölgenin aralıkları zamanla değiştirilebilir.

Bölge çakışması : ortak olan tüm boyutlar için aralıkları çakışıyorsa iki bölge çakışır.

Çalışma zamanında, bir federasyon, nesne sınıfı özniteliklerine ve etkileşimlerine abone olurken Bölgeler sağlayabilir. Bölgeler, öznitelik güncellemeleri ve etkileşimler gönderilirken de kullanılır. DDM kullanıldığında, öznitelik güncellemeleri ve etkileşimler yalnızca bir bölge çakışması varsa teslim edilecektir.

Bölgeler için temel hizmetler şunlardır:

  • Belirtilen Boyutlar kümesiyle bir bölge oluşturmak için kullanılan CreateRegion.
  • Bir bölgeyi silmek için kullanılan DeleteRegion.
  • Bir Bölge için bir boyutun aralıklarını değiştirmek için kullanılan CommitRegionModifications.

DDM ile öznitelik güncellemelerini değiştirmek için temel hizmetler şunlardır:

  • Öznitelikleriyle ilişkili bölgelere sahip bir nesne örneğini kaydetmek için kullanılan RegisterObjectInstanceWithRegions.
  • Bölgeleri bir nesne örneğinin nitelikleriyle ilişkilendirmek için kullanılan AssociateRegionsForUpdates.
  • Abonelik için kullanılan bölgelerin öznitelik bölgeleriyle çakıştığı nesnelerin özniteliklerine abone olmak için kullanılanSubscribeObjectClassAttributesWithRegions.

DDM ile etkileşim alışverişi için temel hizmetler şunlardır:

  • Abonelik için kullanılan bölgelerin etkileşim bölgeleriyle çakıştığı etkileşimlere abone olmak için kullanılanSubscribeInteractionClassWithRegions.
  • İlişkili bölgelerle etkileşimleri göndermek için kullanılan SendInteractionsWithRegions.

Destek Hizmetleri

HLA Arayüz Spesifikasyonunun 10. bölümünde açıklanan HLA Destek Hizmetleri, bir dizi destek hizmeti sağlar. Bunlar şunları içerir:

  • Yukarıdaki servis çağrılarında kullanılacak Alma Kolları (referanslar).
  • Özellikle uyarılar (bildirimler) için çeşitli çalışma zamanı anahtarlarının ayarlanması.
  • Geri aramaların teslimini kontrol etme.

Yönetim Nesnesi Modeli

HLA Arayüz Spesifikasyonunun 11. bölümünde açıklanan Yönetim Nesnesi Modelinin amacı, bir federasyonu yönetmek için hizmetler sağlamaktır. Bu, MOM nesnesi ve etkileşim sınıfları kullanılarak gerçekleştirilir. MOM nesneleri, RTI tarafından otomatik olarak yüklenen MIM adı verilen özel bir FOM modülünde tanımlanır. Temel MOM özellikleri şunları içerir:

  • Federasyonların özelliklerini listeleyin ve inceleyin.
  • Federasyonun özelliklerini inceleyin.
  • Mevcut FOM ve FOM modüllerinin içeriğini alın.
  • Zaman yönetiminin durumunu inceleyin.
  • Federasyonların yayınlarını ve aboneliklerini inceleyin ve değiştirin.
  • Belirli performans rakamlarını inceleyin.
  • Hangi federasyonun hangi HLA hizmetlerini aradığını inceleyin.
  • Senkronizasyon noktalarının durumunu inceleyin.

Nesne modeli şablonu (OMT)

OMT, Federasyon Nesne Modellerini (FOM'ler) ve Simülasyon Nesne Modellerini (SOM'ler) açıklamak için kullanılan bir şablondur. FOM'lar ve SOM'ler tablo biçiminde veya XML kullanılarak gösterilebilir. İkinci format, RTI'ye bir FOM yüklendiğinde kullanılır.

HLA'nın önceki sürümlerinde, FOM'lar monolitikti, ancak standardın mevcut sürümü modüler FOM'ları destekler, yani bilgi alışverişinin farklı yönlerini kapsayan birkaç modül RTI'ye sağlanabilir.

Standartta bir dizi önceden tanımlanmış sınıf, veri türü, boyut ve taşıma türü sağlanmaktadır. Bunlar HLAstandardMIM.xml FOM modülünde sağlanır. Önceden tanımlanmış kavramların önüne HLA eklenir, örneğin HLAobjectRoot ve HLAunicodeString.

OMT için üç farklı XML Şeması vardır:

  • Bir OMT belgesinin temel OMT biçimini izlediğini doğrulayan, ancak eksiksiz olduğunu ve başvuru bütünlüğüne sahip olmadığını doğrulayan OMT DIF XML Şeması.
  • Bir OMT belgesinin bir RTI tarafından faydalı olmak için yeterli bilgi içerdiğini doğrulayan OMT FDD XML Şeması. Bu şemanın Arayüz Spesifikasyonunda sağlandığını unutmayın.
  • Bir OMT belgesinin eksiksiz olduğunu ve referans bütünlüğüne sahip olduğunu doğrulayan OMT Uygunluk Şeması.

Tanımlama Tablosu

Tanımlama tablosunun amacı, FOM/SOM veya federasyonların yeniden kullanımını kolaylaştırmak için model hakkında meta veriler sağlamaktır.

Örnek HLA tanımlama tablosu

Aşağıdaki alanlar belirtilmiştir:

  • Genel: Ad, Tür (FOM/SOM), Sürüm, Değişiklik tarihi, Güvenlik sınıflandırması, Yayın kısıtlaması, Amaç, Uygulama alanı, Açıklama, Kullanım sınırlaması ve Kullanım geçmişi
  • Anahtar Kelimeler: Anahtar kelime değerleri ve Kullanılan Taksonomi
  • İrtibat noktası (POC): Tür (Birincil yazar/Katkıda bulunan/Destekçi/Sponsor/Yayın Yetkilisi/Teknik POC), POC adı, POC organizasyonu, POC telefonu, POC e-postası
  • Referanslar: Tür (Metin belgesi/Elektronik tablo/Powerpoint dosyası/Bağımsız FOM/Bağımlılık FOM/FOM'dan Oluşturulmuş), Tanımlama (belge adı veya FOM adı)
  • Başka
  • Glif (Simge)

Nesne Sınıfları Yapı Tablosu

Nesne sınıfı yapı tablosunun amacı, bir HLA federasyonundaki nesneleri somutlaştırmak için kullanılan nesne sınıflarının sınıf hiyerarşisini (alt sınıf/üst sınıf) belirtmektir. Nesne sınıfı nitelikleri, bu hiyerarşiye dayalı olarak üst sınıflardan alt sınıflara miras alınır. Nesne sınıfı ağacının kökü HLAobjectRoot olarak bilinir. Bir nesne sınıfının tam nitelikli adına bir örnek, HLAobjectRoot.Car.ElectricCar'dır.

Örnek HLA nesne sınıfı tablosu

Hiyerarşideki bir nesne sınıfı için aşağıdaki alanlar belirtilir:

  • İsim
  • Yayın (Yayınla/Abone Ol/Yayınla/Hiçbiri)

Özellik Tablosu

Öznitelik tablosunun amacı, belirli bir nesne sınıfı için mevcut olan öznitelikleri belirtmektir. Nitelikler miras alındığından, bir nesne sınıfı, nesne sınıfında yerel olarak tanımlanan veya herhangi bir doğrudan veya dolaylı üst sınıfta belirtilen tüm niteliklerin birleşimine sahip olacaktır.

Örnek HLA öznitelik tablosu

Bir öznitelik için aşağıdaki alanlar belirtilmiştir

  • Tanımlandığı nesne sınıfı adı
  • Özellik adı
  • Veri Türü Tablosunda tanımlanan Veri Türü (aşağıya bakın)
  • Güncelleme türü (Statik/Periyodik/Koşullu/NA)
  • Durumu güncelle
  • D/A (Divest/Acquire/NoTransfer/DivestAcquire): Niteliğin elden çıkarılıp çıkarılamayacağı veya HLA Mülkiyet Hizmetleri kullanılarak elde edilip edilemeyeceği
  • P/S (Yayınla/Abone Ol/Yayınla/Hiçbiri): Özelliğin yayınlanıp yayınlanamayacağı ve/veya abone olunabileceği. Bir SOM'da bu bilgi, açıklanan Federasyon ile, FOM'da ise tüm federasyonla ilgilidir.
  • Mevcut Boyutlar
  • Taşıma (Güvenilir/BestEffort/Nakliye tablosunda açıklanan diğer taşımalar)
  • Sipariş (Alma/Zaman Damgası): Öznitelik güncellemeleri için teslimat siparişi.

Etkileşim Sınıfı Yapı Tablosu

Etkileşim sınıfı yapısı tablosunun amacı, bir HLA federasyonunda etkileşimleri değiştirmek için kullanılan etkileşim sınıflarının sınıf hiyerarşisini (alt sınıf/üst sınıf) belirtmektir. Etkileşim sınıfı parametreleri, bu hiyerarşiye dayalı olarak üst sınıflardan alt sınıflara miras alınır. Etkileşim sınıfı ağacının kökü, HLAinteractionRoot olarak bilinir. Etkileşim sınıfının tam nitelikli adına bir örnek, HLAinteractionRoot.CarCommand.Start'tır.

Örnek HLA etkileşim sınıfı tablosu

Hiyerarşide bir etkileşim sınıfı için aşağıdaki alanlar belirtilmiştir:

  • İsim
  • Yayın (Yayınla/Abone Ol/Yayınla/Hiçbiri)

Parametre Tablosu

Parametre tablosunun amacı, belirli bir etkileşim sınıfı için mevcut olan parametreleri belirtmektir. Parametreler miras alındığından, bir etkileşim sınıfı, etkileşim sınıfında yerel olarak tanımlanan veya herhangi bir doğrudan veya dolaylı üst sınıfta belirtilen tüm parametrelerin birleşimine sahip olacaktır.

Örnek HLA parametre tablosu

Boyutlar tablosu

Boyutlar tablosunun amacı, nitelikler ve etkileşim sınıfları için kullanılan DDM boyutlarını belirtmektir.

Zaman gösterim tablosu

Zaman gösterim tablosunun amacı, Zaman Yönetimi servisleri tarafından kullanılan veri tiplerini belirtmektir.

Kullanıcı tarafından sağlanan etiket tablosu

Belirli HLA servisleri aranırken, kullanıcı tarafından sağlanan bir etiket sağlanabilir. Kullanıcı tarafından sağlanan etiket tablosunun amacı, bu etiketlerin veri türlerini belirtmektir.

senkronizasyon tablosu

Senkronizasyon tablosunun amacı, bir federasyonda kullanılan senkronizasyon noktalarını belirtmektir.

Taşıma türü tablosu

Taşıma türü tablosunun amacı, mevcut taşıma türlerini belirtmektir. Önceden tanımlanmış iki taşıma türü vardır: HLAreliable ve HLAbestEffort.

Oran tablosunu güncelle

Güncelleme hızı tablosunun amacı, mevcut maksimum güncelleme oranlarını belirtmektir.

Anahtarlar tablosu

RTI'nin çalışma zamanı davranışı, önceden tanımlanmış bir dizi anahtar kullanılarak kontrol edilebilir. Anahtar tablosunun amacı, bu anahtarlar için başlangıç ​​değerleri sağlamaktır. Anahtarlardan bazıları çalışma zamanında da güncellenebilir.

Veri tipleri

Veri türü tablolarının amacı, öznitelikler, parametreler, boyutlar, zaman gösterimi, kullanıcı tarafından sağlanan etiket ve senkronizasyon noktaları için kullanılan veri türlerinin özelliklerini sağlamaktır. Her biri için ayrı bir tablo biçiminde altı veri türü kategorisi vardır.

Temel Veri Temsil Tablosu

Temel veri gösterim tablosunun amacı, diğer tablolarda kullanılmak üzere ikili gösterimler sağlamaktır. HLA standardında önceden tanımlanmış bir dizi temel veri türü sağlanır: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteger64LE, HLAfloat32LE, HLA. Temel veri türleri kümesi genellikle kullanıcı tanımlı temel veri türleri ile genişletilmez.

Basit Veri Tipleri Tablosu

Örnek HLA basit veri türü tablosu

Basit veri türleri tablosunun amacı, basit skaler veri öğelerini tanımlamaktır. HLA standardında bir dizi önceden tanımlanmış basit veri türü sağlanmıştır: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time ve HLAfloat64time. Bir FOM'a kullanıcı tanımlı basit veri tiplerini dahil etmek yaygındır.

Numaralandırılmış Veri Tipleri Tablosu

Örnek HLA numaralandırılmış veri türü tablosu

Numaralandırılmış veri türleri tablosunun amacı, sonlu ayrık değerler kümesini alabilen veri öğelerini tanımlamaktır. Standartta önceden tanımlanmış bir numaralandırılmış veri türü sağlanır: HLAboolean. Bir FOM'a kullanıcı tanımlı numaralandırılmış veri türlerini dahil etmek yaygındır.

Dizi Veri Tipleri Tablosu

Örnek HLA dizisi veri türü tablosu

Numaralandırılmış veri türleri tablosunun amacı, veri öğelerinin dizilerini (basit, numaralandırılmış, diziler, sabit kayıtlar veya değişken kayıtları) tanımlamaktır. HLA standardında bir dizi önceden tanımlanmış basit veri türü sağlanır: HLAASCIIstring, HLAunicodeString, HLAopaqueData ve HLAtoken. Bir FOM'a kullanıcı tanımlı dizi veri tiplerini dahil etmek yaygındır.

Sabit Kayıt Veri Tipleri Tablosu

Örnek HLA sabit kayıt veri türü tablosu

Sabit kayıt veri türleri tablosunun amacı, sabit bir dizi veri öğesiyle (basit, numaralandırılmış, diziler, sabit kayıtlar veya değişken kayıtlar) kayıtları tanımlamaktır. Bir FOM'a kullanıcı tanımlı basit veri tiplerini dahil etmek yaygındır. HLA standardında önceden tanımlanmış basit veri türleri sağlanmaz.

Varyant Kaydı Veri Tipleri Tablosu

Notlar tablosu

Notların amacı, tablonun diğer tablolardaki öğelerin açıklamalarını ve ek açıklamalarını sağlamaktır.

HLA kuralları

HLA kuralları, federasyonların ve katılan federasyonların sorumluluklarını tanımlar.

  1. Federasyonların, HLA nesne modeli şablonuna (OMT) göre belgelenmiş bir HLA federasyon nesne modeli (FOM) olacaktır.
  2. Bir federasyonda, nesnelerin FOM'daki tüm temsili, çalışma zamanı altyapısında (RTI) değil, federasyonlarda olacaktır.
  3. Bir federasyon yürütmesi sırasında, federasyonlar arasındaki tüm FOM verilerinin değişimi RTI aracılığıyla gerçekleşir.
  4. Bir federasyon yürütmesi sırasında, federasyonlar, HLA arabirim belirtimine uygun olarak çalışma zamanı altyapısı (RTI) ile etkileşime girecektir.
  5. Bir federasyon yürütmesi sırasında, bir nesnenin bir örneğinin özniteliği, herhangi bir zamanda yalnızca bir federasyona ait olacaktır.
  6. Federasyonlar, HLA nesne modeli şablonuna (OMT) uygun olarak belgelenmiş bir HLA simülasyon nesne modeline (SOM) sahip olacaktır.
  7. Federasyonlar, SOM'larındaki nesnelerin herhangi bir özniteliğini güncelleyebilecek ve/veya yansıtabilecek ve SOM'larında belirtildiği gibi SOM nesne etkileşimlerini harici olarak gönderebilecek ve/veya alabilecektir.
  8. Federasyonlar, SOM'larında belirtildiği gibi, bir federasyon yürütmesi sırasında dinamik olarak bir özniteliğin sahipliğini aktarabilecek ve/veya kabul edebilecektir.
  9. Federasyonlar, SOM'larında belirtildiği gibi, nesnelerin özniteliklerinin güncellemelerini sağladıkları koşulları değiştirebilecektir.
  10. Federasyonlar, yerel saati, bir federasyonun diğer üyeleriyle veri alışverişini koordine etmelerine izin verecek şekilde yönetebilmelidir.

HLA Evrimleşmiş

IEEE 1516 standardı, SISO HLA-Evolved Product Development Group altında revize edildi ve 25 Mart 2010'da IEEE Standartları Faaliyetleri Kurulu tarafından onaylandı. Revize edilmiş IEEE 1516–2010 standardı, mevcut DoD standart yorumlarını ve SISO DLC API'sinin genişletilmiş bir versiyonu olan EDLC API'sini içerir. Diğer önemli iyileştirmeler şunları içerir:

  • FOM/SOM için Şemalar ve genişletilebilirlik gibi genişletilmiş XML desteği
  • Hata toleransı destek hizmetleri
  • Web Hizmetleri (WSDL) desteği/API
  • Modüler FOM'lar
  • Güncelleme oranı indirimi
  • Kodlama yardımcıları
  • Ek taşıma için genişletilmiş destek (QoS, IPv6,... gibi)
  • Standartlaştırılmış zaman gösterimleri

Federasyon Uygunluğu

Simülasyonlar arasında uygun etkileşimi sağlamak için, federasyon uyumluluğunu test etmenin bir yolu tanımlanır. Bu, belirli bir federasyon için SOM'da listelenen her sınıfın ve etkileşimin, "YayınlaAbone Ol", "Yayınla", "Abone Ol" veya "Yok" olarak açıklanan kullanıma göre kullanılmasını sağlamayı içerir.

STANAG 4603

HLA (hem mevcut IEEE 1516 sürümünde hem de onun atası "1.3" sürümünde) modelleme ve simülasyon için NATO standardizasyon anlaşmasının (STANAG 4603) konusudur : Teknik Birlikte Çalışabilirlik İçin Modelleme ve Simülasyon Mimarisi Standartları: Yüksek Düzey Mimari (HLA) .

İlgili standartlar

Temel Nesne Modeli

Baz nesne modeli (BOM), alıcıda yüksek-STD-003-2006 ile ilgili standart SISO HLA simülasyonlar için iyi bir yeniden kullanım ve Birleştirmeyi sağlamaktır. Kavramsal modelleri belirlemenin ve bunların bir HLA FOM'a nasıl eşleneceğinin bir yolunu sağlar.

alternatifler

Dağıtılmış Modelleme ve Simülasyon (DM&S) endüstrisi ile ilgili olarak, askeri platformların gerçek zamanlı simülasyonu için HLA'ya en sık kullanılan alternatif , bir simülasyon protokolü olan Dağıtılmış Etkileşimli Simülasyon (DIS), IEEE 1278.1-2012'dir. Çoğu HLA RTI satıcısı , ürünlerinde DIS'e de yer verir. Yayınla ve abone ol özelliği (P&S) gibi HLA özellikleriyle en yakından eşleşen ara katman yazılımı uygulamalarına gelince , aynı özelliklerin çoğunu paylaşan ancak sistem birlikte çalışabilirliği için açık bir kablolu protokole sahip olan Veri Dağıtım Hizmeti'ne (DDS) bakın .

eleştiri

HLA, bir C++ veya Java API tarafından sağlanan bir dizi hizmet olarak tanımlanan Mesaj odaklı bir ara katman yazılımıdır . Standartlaştırılmış bir on-the-wire protokolü yoktur. Bir federasyondaki katılımcılar, aynı sağlayıcıdan ve genellikle aynı sürümden RTI kitaplıkları kullanmalıdır, bu da bazı durumlarda bir dezavantaj olarak algılanır. Güncel araçların çoğu ayrıca soketler aracılığıyla ara bağlantı sağlar.

Ayrıca bakınız

Referanslar

Dış bağlantılar