Arsitektur Tingkat Tinggi (HLA) versus Simulasi Interaktif Terdistribusi (DIS)

Saat ini saya (meskipun hanya sekitar seminggu lagi) bekerja di industri simulasi - Saya mohon maaf sebelumnya atas kesalahan apa pun, saya akan memperbaikinya jika saya mengingat informasi yang salah.

DIS

• Standar ini menentukan tata letak data pada kabel, yaitu paket/PDU data Anda ditata persis seperti yang ditentukan dalam spesifikasi DIS

• Mengandalkan jaringan upaya terbaik (yaitu protokol UDP, penyiaran)

• Entitas harus berdetak pada interval tertentu (default: 5 detik) untuk memberi tahu semua orang bahwa itu masih merupakan bagian dari latihan

• Tidak ada server pusat yang mengelola berbagai aplikasi yang tergabung dalam latihan

• Aplikasi simulasi dapat bergabung dengan simulasi kapan saja, keluar kapan saja

HLA

• Menggunakan manajer pusat, yang disebut RTI (Run Time Infrastructure), yang menerima data dari berbagai aplikasi dan mengirimkannya ke aplikasi lain dalam simulasi (dalam konteks HLA, ini disebut Federasi dan kumpulan Federasi adalah Federasi)

• Seluruh federasi harus mengikuti dan keluar dari simulasi dengan melalui RTI

• Berbeda dengan DIS, spesifikasi HLA tidak menentukan tata letak paket data, melainkan mendefinisikan sekumpulan fungsionalitas API yang digunakan aplikasi. RTI inilah yang mengimplementasikan API.

• Federasi HLA mempublikasikan data berdasarkan FOM (Federation Object Model) yang mendefinisikan apa yang diwakili oleh data dalam simulasi. Hal ini memungkinkan orang untuk membuat FOM baru yang mendefinisikan objek baru dan tipe interaksi, tidak seperti di DIS, di mana penambahan tipe data baru PDU dilakukan melalui komite (SISO). Misalnya, sebagian besar simulasi yang berjalan di bawah HLA menggunakan RPR FOM, yang mencerminkan entitas dan interaksi standar DIS.

• HLA menambahkan fitur tambahan yang tidak didukung DIS, seperti Manajemen Distribusi Data (DDM), yang mana federasi memberi tahu RTI bahwa mereka hanya tertarik pada jenis data tertentu.

• Mendukung layanan berlangganan, dimana federasi memberi tahu RTI bahwa mereka hanya tertarik untuk menerima objek atau data interaksi tertentu (yaitu aplikasi hanya menginginkan data tentang kapal)

• Mendukung fitur pengalihan kepemilikan, di mana objek yang berada di bawah kendali satu federasi diberikan kepada federasi lain untuk dikelola.

Dapatkah DIS menghosting HLA dan Sebaliknya?

Karena perbedaan mendasar ini, jelas bahwa DIS dan HLA tidak dapat saling menampung.

Namun, hal ini sebenarnya berarti agar simulasi di DIS dapat berinteraksi dengan simulasi di HLA, Anda memerlukan beberapa jenis broker jaringan yang bertindak sebagai adaptor antara kedua protokol. Contoh broker tersebut adalah MAK VR-Exchange atau Gerbang UGM.

Untuk bacaan lebih lanjut:

• http://www.mak.com/products/standards.php
• http://www.siaa.asn.au/get/2395379411.pdf
• http://dss.ll.mit.edu/dss.web/96.14.103.RTI.Introduction.html

Berikut adalah beberapa sejarah yang kurang diketahui mengenai HLA.

Desain HLA sebenarnya didasarkan pada sesuatu yang disebut Protokol Simulasi Tingkat Agregat (ALSP) yang dipimpin pada awal tahun 90an oleh orang-orang Mitre yang sama yang mengembangkan HLA. ALSP dirancang untuk menghubungkan simulasi konstruktif berskala besar yang digunakan untuk Pelatihan Pos Komando Korps/Divisi. Persyaratan untuk interoperabilitas ALSP melibatkan jumlah objek yang lebih besar, sinkronisasi waktu yang konservatif, dan pertukaran peristiwa simulasi. Kami tidak dapat menyiarkan pembaruan entitas secara berkala karena hal itu akan menyebabkan masalah skalabilitas.

Pada tahun-tahun terakhir keterlibatan saya, kami mencapai sebanyak 1 juta objek medan perang per satu latihan Lensa Fokus Ulchi. Perbedaan mendasar antara HLA dan DIS adalah bahwa HLA dirancang untuk menangani simulasi konstruktif berskala besar, fidelitas variabel, dan dikelola waktu yang konservatif, sedangkan DIS lahir dari lingkungan simulator jaringan dan berfokus pada simulator tingkat platform yang hampir real-time.

HLA dapat membantu membuat kedua kelas simulasi ini saling beroperasi hingga tingkat tertentu, namun akan selalu dibatasi oleh perbedaan inheren dalam jenis simulasi yang dihubungkan.

Misalnya, jika federasi simulasi terkelola waktu yang konservatif terjebak dalam penghitungan, manajemen waktu HLA akan menyebabkan federasi berhenti memajukan waktu hingga simulasi yang paling lambat bergerak maju. DIS tidak mendukung hal ini. Pada platform yang digerakkan oleh DIS, semua entitas yang dikelola waktu akan tampak bergerak dalam gerakan lambat atau berhenti sama sekali dan secara berkala akan tampak bergerak lebih cepat daripada waktu nyata ketika federasi mencoba mengejar ketertinggalan waktu nyata.

Tidak ada spesifikasi HLA yang menyatakan bahwa RTI harus terpusat, meskipun hampir semua RTI harus terpusat.

Standar HLA 1516 hanya mendefinisikan API antara simulator dan RTI. Bukan antar RTI. Protokol yang digunakan untuk bertukar data antar RTI bersifat eksklusif. Oleh karena itu, hanya RTI dari vendor atau lembaga pemerintah yang sama yang dapat saling beroperasi. Sebuah kelemahan besar. Jika Anda menggunakan RTI yang berbeda, Anda memerlukan "jembatan" untuk menerjemahkan antar protokol kepemilikan. Ini bisa mahal.

Satu hal yang perlu diingat jika Anda berencana untuk menjembatani DIS dan HLA adalah Anda mungkin akan kehilangan fidelitas simulasi di kedua sisi tergantung pada bagaimana FOM Anda diatur. DIS ke RPR FOM sangatlah mudah tetapi ada FOM lain di luar sana yang mungkin tidak terpetakan dengan baik ke DIS. Dalam beberapa situasi, Anda mungkin tidak dapat menerjemahkan bidang PDU ke atribut objek HLA atau parameter interaksi (atau sebaliknya). Anda harus menggunakan penilaian terbaik Anda mengenai jenis nilai default apa yang akan digunakan dalam situasi ini. Di lain waktu, hierarki objek HLA FOM mungkin memiliki struktur yang sangat berbeda dari DIS. Dalam hal ini penerjemahan mungkin memerlukan penggabungan data dari beberapa PDU DIS untuk membentuk satu pesan HLA. Ini berarti Anda harus menulis kode di jembatan untuk mempertahankan beberapa bentuk status pesan.

Selain itu, saat runtime Anda akan mendapatkan atribut HLA Anda sedikit demi sedikit. Setelah penemuan objek, Anda harus menunggu untuk menerjemahkan instance objek hingga Anda menerima atribut yang cukup untuk mengisi DIS PDU dengan benar.

Masalah lainnya adalah HLA dapat menyediakan layanan manajemen waktu. Anda akan menghadapi banyak masalah sinkronisasi jika Anda mencoba mengintegrasikan aplikasi DIS ke dalam federasi HLA menggunakan manajemen waktu.

Jika Anda memiliki anggaran pembelian, saran saya adalah menggunakan MAK VR-Exchange.