Clever Geek Handbook

Sistem Simulasi Terdistribusi



Untuk dapat menggabungkan masing-masing simulator ke dalam sistem simulasi terdistribusi, standar dan teknologi berikut saat ini digunakan:



  • IEEE1516 (juga menggantikan HLA dan DIS)
  • OPC;
  • CAPE-OPEN dan standar "industri" lainnya.


Yang paling menarik adalah standar IEEE 1516, karena standar ini berkaitan langsung dengan simulator, ditujukan untuk membangun sistem simulasi terdistribusi (protokol, metode kontrol dan umpan balik yang disarankan, arsitektur sistem, dll.).



Keluarga teknologi perangkat lunak OPC (OLE untuk Kontrol Proses) yang menyediakan antarmuka tunggal untuk mengelola objek otomasi dan proses teknologi juga sangat menarik, tetapi hanya jika integrasi dengan objek otomatisasi dan proses teknologi diperlukan. Standar CAPE-OPEN digunakan untuk interaksi simulator yang dirancang khusus untuk industri kimia.



Institute of Electrical and Electronic Engineers (IEEE) telah memberikan kontribusi signifikan terhadap standardisasi pemodelan dan simulasi. Pemodelan terdistribusi (simulasi) adalah teknologi untuk pertukaran data antara simulator melalui jaringan komputer lokal atau global. Ini memungkinkan masing-masing simulator untuk bekerja bersama sebagai satu pemodelan terkontrol atau sistem simulasi. Konsep pemodelan terdistribusi didasarkan pada penggunaan arsitektur tingkat tinggi (HLA). Dalam praktiknya, standar IEEE 1516 mendefinisikan arsitektur dengan menggunakan API tunggal (antarmuka pemrograman aplikasi). Postulat awal standar adalah:



  1. model simulasi "monolitik" sederhana tidak dapat memenuhi kebutuhan pengguna profesional;
  2. semua kemungkinan aplikasi simulasi tidak diketahui sebelumnya;
  3. kemungkinan kombinasi sewenang-wenang dari simulator individu ke dalam sistem simulasi yang kompleks harus disediakan;
  4. Arsitektur pemodelan terdistribusi harus seterbuka mungkin untuk teknologi pemodelan dan simulasi di masa depan.


Saat ini, IEEE 1516 adalah standar absolut untuk interaksi simulator dan simulator dalam aplikasi militer, karena persyaratan yang ketat untuk kompatibilitas dengan simulator yang dikembangkan dan digunakan oleh Departemen Pertahanan AS dan NATO. Saat ini, IEEE 1516 semakin banyak digunakan di bidang sipil, dalam pengembangan simulator untuk melatih personel sistem teknis yang kompleks, dalam penerbangan, astronotika, transportasi, dll.



Rangkaian teknologi perangkat lunak OPC telah dirancang untuk mengurangi biaya pembuatan dan pemeliharaan aplikasi otomasi industri. Pada awal 90-an, pengembang perangkat lunak industri membutuhkan alat universal untuk bertukar data dengan perangkat dari produsen yang berbeda atau dengan protokol komunikasi yang berbeda. OPC menyediakan pengembang perangkat lunak industri dengan antarmuka tetap universal untuk pertukaran data dengan perangkat apa pun. Pada saat yang sama, pengembang perangkat menyediakan program yang mengimplementasikan antarmuka ini.



Untuk membuat sistem simulasi yang kompleks, Anda dapat menggabungkan penggunaan IEEE 1516 dan OPC, mendapatkan kesempatan untuk menggunakan peralatan nyata dan sistem SCADA (gambar), yang dapat sangat berguna dalam banyak tugas.



Komunikasi antara standar IEEE 1516 (yang merupakan dasar untuk simulator) dan OPC (digunakan dalam sistem SCADA) dapat diimplementasikan baik secara langsung dalam simulator dan melalui perantara. Peran perantara seperti itu, misalnya, bagi saya, dilakukan oleh paket National Instruments LabView. LabView dapat mendukung model matematika dari kompleksitas apa pun, memiliki dukungan OPC bawaan, dapat bertindak sebagai server OPC, memiliki dukungan efektif untuk interaksi dengan berbagai kartu I / O, yang memungkinkan Anda untuk menggunakan peralatan yang diperlukan secara langsung, tetapi, sayangnya, tidak memiliki sarana interaksi dengan IEEE 1516 , yang mengharuskan penulisan komponen perangkat lunak yang sesuai.



Sebagai hasil dari penggunaan IEEE 1516 dan OPC, dimungkinkan untuk membuat sistem simulasi terdistribusi yang relatif kompleks, termasuk banyak simulator, peralatan nyata, sistem SCADA, dll.



Masalah sertifikasi simulator atau simulator sehubungan dengan dukungan standar IEEE 1516 patut mendapat pertimbangan terpisah . federasi dalam terminologi IEEE 1516) dan pustaka perangkat lunak yang mengimplementasikan interaksi. Tetapi tujuan dari sertifikasi ini bukan untuk mengidentifikasi cacat fungsional dari program (hanya sertifikasi dukungan untuk standar IEEE 1516).



Organisasi yang mampu sertifikasi:



  • AMERIKA SERIKAT. Kantor Koordinasi Modeling dan Simulasi Departemen Pertahanan (DoD) (M&S CO). Situs web: www.msco.mil
  • . ONERA. (Office National d’Etudes et Recherches Aérospatiales) is the French national aerospace research center. : www.onera.fr
  • . Pitch Technologies AB. : www.pitch.se














Mari kita bahas masalah membangun sistem simulasi terdistribusi berdasarkan standar IEEE 1516. Istilah dasar yang digunakan dalam dukungan informasi sesuai dengan terminologi sistem simulasi interaktif terdistribusi IEEE 1516 - mereka adalah federasi, federasi, objek, atribut dan interaksi. Konsep suatu objek didefinisikan sebagai model dari fenomena yang terpisah di dunia nyata. Objek tidak memiliki metode, mereka hanya memiliki status (hanya struktur data tanpa fungsi untuk memprosesnya). Keadaan objek dicirikan oleh set atribut tetap - nilai tepat yang dapat berubah seiring waktu. Setiap objek setiap saat ditandai dengan keadaannya, yang ditentukan oleh serangkaian nilai atribut saat ini. Federasi adalah deskripsi matematis dari perilaku objek - model simulasi,software-defined (diimplementasikan dalam bahasa direktif) atau diwakili oleh nilai-nilai sensor perangkat keras. Bahkan, FBI dapat berupa peniru dan peralatan nyata atau perangkat lunak khusus. Satu-satunya persyaratan adalah menyediakan antarmuka yang seragam untuk komunikasi. Federasi dapat memanipulasi objek dengan mengubah (memperbarui) atau mendapatkan (menampilkan) nilai atribut mereka. Khususnya, pengguna peniru juga merupakan federasi. Agregat dari semua federasi yang berpartisipasi dalam simulasi membentuk federasi.Satu-satunya persyaratan adalah menyediakan antarmuka yang seragam untuk komunikasi. Federasi dapat memanipulasi objek dengan mengubah (memperbarui) atau mendapatkan (menampilkan) nilai atribut mereka. Khususnya, pengguna peniru juga merupakan federasi. Agregat dari semua federasi yang berpartisipasi dalam simulasi membentuk federasi.Satu-satunya persyaratan adalah menyediakan antarmuka yang seragam untuk komunikasi. Federasi dapat memanipulasi objek dengan mengubah (memperbarui) atau mendapatkan (menampilkan) nilai atribut mereka. Khususnya, pengguna peniru juga merupakan federasi. Agregat dari semua federasi yang berpartisipasi dalam simulasi membentuk federasi.



Istilah "interaksi" didefinisikan sebagai pesan instan (peristiwa) yang tidak terikat pada instance objek atau federasi tertentu, yang terjadi pada tingkat federasi (yaitu, tidak mungkin untuk menentukan pengirim). Interaksi, berbeda dengan keadaan objek, tidak terus-menerus dipertahankan dalam sistem, tetapi bersifat instan. Contohnya adalah siaran pesan teks satu arah ke semua anggota federasi yang tertarik. Skema federasi hierarkis (HLA / IEEE 1516) ditunjukkan pada gambar



Interaksi federasi dilakukan dengan menggunakan mekanisme interaksi umum (RTI), diimplementasikan sebagai berlangganan. Federasi yang tertarik untuk memperoleh atribut dan interaksi tertentu dari federasi lain harus berlangganan melalui RTI. Mekanisme untuk meminta, menyediakan, dan mengubah nilai atribut ditunjukkan pada gambar. Mekanisme untuk mengatur simulasi dan kolaborasi didistribusikan ditunjukkan pada gambar.





Gambar. Skema federasi hierarkis



Objek dalam simulator adalah, sebagai aturan, model 3D, sumber suara, masing-masing, atribut dari objek tersebut adalah posisi dan orientasi dalam ruang, ukuran, volume, dll. Berkenaan dengan simulator, tindakan pengguna (federasi), misalnya, dimasukkannya kunci, dapat dianggap sebagai interaksi.





. (RTI)





. (RTI)





.



Ketika membuat sistem simulasi terdistribusi yang berinteraksi melalui RTI, perlu untuk mempertimbangkan fitur-fitur penting berikut. Semua elemen federasi dan federasi harus didokumentasikan dalam file tertentu (FOM (model objek federasi) file digunakan untuk menggambarkan federasi), federasi dijelaskan dalam file SOM (Model Obyek Simulasi). Semua data disimpan hanya dalam federasi, RTI tidak menyimpan data apa pun, tetapi hanya mentransfernya. HLA hanya memungkinkan satu federasi untuk mengubah nilai atribut pada waktu tertentu (ada mekanisme manajemen hak khusus untuk mentransfer hak). Federasi dapat mengelola waktu lokal, HLA menggunakan berbagai mekanisme manajemen waktu internal (sinkronisasi).



Secara umum, standar IEEE 1516 membahas sejumlah besar masalah yang berkaitan dengan pembuatan sistem simulasi terdistribusi, seperti mempertahankan status federasi, memperbarui status, berbagai mekanisme sinkronisasi waktu, bidang interaksi federasi, dll. Sehubungan dengan volume signifikan dari standar itu sendiri dan, terlebih lagi, volume kode program untuk menunjukkan semua aspek yang dijelaskan dalam standar, hanya implementasi mendasar dari kemampuan "dasar" yang akan ditunjukkan di bawah ini (gambar).





Gambar. Diagram Blok Implementasi Kemampuan Dasar IEEE 1516



Presentasi implementasi yang lebih rinci dikaitkan dengan kebutuhan untuk menyajikan daftar program yang cukup besar, untuk alasan ini, pembaca dapat secara mandiri menggunakan contoh program yang disertakan dengan perangkat lunak untuk mendukung RTI. Contoh-contoh sederhana dengan banyak komentar dimasukkan dalam perpustakaan Proyek Portico dan tersedia secara bebas di porticoproject.org . Hampir semua implementasi komersial dari standar ini juga mengandung banyak contoh.



Sebagai contoh, perhatikan federasi berikut, yang terdiri dari dua federasi: mobil yang dikendalikan radio dan panel kontrol. Misalkan kontrol dilakukan dengan mengatur kecepatan masing-masing dari 4 mesin mobil dan memutar roda depan. Mesin ini dilengkapi dengan sensor yang menentukan jarak ke penghalang dan mentransmisikan sinyal ke panel kontrol. Untuk ini perlu mendefinisikan dua kelas objek, cYpravlenie untuk panel kontrol dan cDatchik untuk sensor jarak. Atribut dari kelas cYpravlenie adalah wheel1, wheel2, wheel3, wheel4, wheel_angle. Atribut kelas cDatchik adalah jarak. Berikut ini adalah file deskripsi federasi, dalam format HLA 1.3 (interaksi diberikan sebagai contoh). 



;;  —   (FED )   HLA 1.3

(Fed 
  (Federation Test) 
  (FedVersion v1.3) 
  (Federate "fed" "Public") 
  (Spaces 
	(Space "Geo" 
		(Dimension X) 
		(Dimension Y) 
	) 
  ) 

(Objects 
	(Class cYpravlenie 
		(Attribute wheel1 reliable timestamp) 
		(Attribute wheel2 reliable timestamp) 
		(Attribute wheel3 reliable timestamp) 
		(Attribute wheel4 reliable timestamp) 
		(Attribute wheel_angle reliable timestamp) 
	) 
	(Class cDatchik 
		(Attribute distance reliable timestamp) 
	) 
) 
	 
(Interactions 
	(Class reaction BEST_EFFORT RECEIVE 
	(Sec_Level "Public") 
		(Parameter dx) 
		(Parameter dy) 
		(Parameter dz) 
	) 
) 

)


Selanjutnya, simulator yang mewakili kontrol menciptakan federasi dan objek berdasarkan kelas cYpravlenie. Simulator yang mewakili mobil juga menciptakan federasi dan objek berdasarkan kelas cDatchik. Federasi juga berlangganan perubahan yang mereka minati, yaitu Mesin gabungan berlangganan untuk menerima data objek dari kelas cYpravlenie (mis., Kelas cYpravlenie), dan kontrol federated ke kelas cDatchik. Dengan demikian, mesin menerima perubahan dari panel kontrol, dan panel kontrol menerima data dari sensor di dalam mobil.



Membangun sistem simulasi yang lebih canggih membutuhkan desain yang serius. Pertama, perlu untuk menentukan komposisi utama federasi dalam pendekatan pertama, yaitu federasi, objek federasi, dan atribut objek. Saat menyusun skema federasi, perlu untuk memperhitungkan komponen perangkat keras dari sistem simulasi terdistribusi, yaitu sensor dan perangkat keras kontrol yang juga harus diwakili dalam bentuk federasi, objek, dan atribut. Di gambar. menunjukkan struktur federasi simulator pemasangan pompa batang pengisap.





Gambar. Struktur Federasi



Setelah federasi tersusun, perlu untuk mendefinisikan tautan, yaitu refleksi dari mana federasi mempublikasikan (yaitu, mengubah) atribut-atribut objek, dan mana yang berlangganan perubahan atribut-atribut ini. Sebagai aturan, pada tahap mendefinisikan tautan, sejumlah besar "amandemen" dibuat untuk struktur federasi. Setelah jumlah iterasi yang diperlukan dari "penyempurnaan" dari struktur dan hubungan, desainer harus menetapkan fakta dari "model yang benar" dari federasi. Contoh mendefinisikan tautan ditunjukkan pada gambar (objek tanpa tautan disembunyikan).





Gambar. Contoh tahap pertama dari mendefinisikan tautan



Pada tahap berikutnya, jumlah komputer yang dibutuhkan ditentukan dan distribusi federasi yang sesuai. Misalnya, federasi "A" akan berfungsi di komputer "1", federasi "B, C, D" akan berfungsi di komputer "2".





Gambar. Distribusi federasi oleh komputer



Sebagai aturan, distribusi federasi didasarkan pada ekonomi model matematika mereka, jika model matematika federasi tidak memerlukan sumber daya komputasi yang signifikan, maka satu komputer dapat digunakan, jika model matematika federasi memerlukan sumber daya komputasi yang signifikan, maka perlu untuk menentukan jumlah komputer dan distribusi federasi yang sesuai.



Langkah selanjutnya adalah membuat file deskripsi federasi (lihat contoh di atas) yang mencerminkan "model yang benar" dari federasi. Anda kemudian membuat implementasi perangkat lunak federasi dengan menulis kode yang sesuai untuk berinteraksi dengan RTI dan kode untuk mengimplementasikan model matematika federasi. Pada tahap akhir, perlu untuk menguji sistem simulasi terdistribusi, mengidentifikasi kesalahan, "kelebihan" komponen tertentu dalam sistem (berdasarkan statistik), sinkronisasi yang benar, dll.



Statistik untuk setiap federasi secara terpisah dan untuk federasi secara keseluruhan menunjukkan jumlah dan jenis pertanyaan yang dieksekusi dan memungkinkan Anda untuk mengidentifikasi kemungkinan masalah selama pengoperasian sistem.



Contoh statistik untuk federasi: 



RTIA: Statistics (processed messages)
Joined federation as car_federate
Synchronization point announced: ReadyToRun
Achieved sync point: ReadyToRun, waiting for federation...
Federation Synchronized: ReadyToRun
Time Policy Enabled
Published and Subscribed
Add instance object: obj_datchik
Removing temporary file _RTIA_3033_ExampleFederation.fed on resign federation.
Resigned from Federation
Didn't destroy federation, federates still joined
List of federate initiated services 
--------------------------------------------------
1 Message::CLOSE_CONNEXION (MSG#1)
1 Message::DESTROY_FEDERATION_EXECUTION (MSG#3)
1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
1 Message::RESIGN_FEDERATION_EXECUTION (MSG#5)
1 Message::SYNCHRONIZATION_POINT_ACHIEVED (MSG#10)
1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
1 Message::SUBSCRIBE_INTERACTION_CLASS (MSG#34)
1 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
1708 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
855 Message::TIME_ADVANCE_REQUEST (MSG#91)
3 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
6 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
1 Message::GET_INTERACTION_CLASS_HANDLE (MSG#116)
120516 Message::TICK_REQUEST (MSG#141)
2564 Message::TICK_REQUEST_NEXT (MSG#142)
List of RTI initiated services 
--------------------------------------------------
1 NetworkMessage::ANNOUNCE_SYNCHRONIZATION_POINT (MSG#13)
1 NetworkMessage::FEDERATION_SYNCHRONIZED (MSG#15)
1 NetworkMessage::DISCOVER_OBJECT (MSG#43)
1711 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
49 NetworkMessage::GET_FED_FILE (MSG#84)
Number of Federate messages : 125662
Number of RTIG messages : 1763
RTIA: Federate destroyed
TCP Socket 3 : total = 122015 Bytes sent 
TCP Socket 3 : total = 340249 Bytes received
UDP Socket 4 : total = 0 Bytes sent 
UDP Socket 4 : total = 0 Bytes received
	     :
CERTI RTIG up and running ... 
New federation: ExampleFederation 
Looking for FOM file... 
   Trying... open_test.fed --> cannot access. 
   Now trying.../usr/local/share/federations/open_test.fed... opened. 

 TCP Socket  7 : total =    340400 Bytes sent 
 TCP Socket  7 : total =    122015 Bytes received 
 UDP Socket  4 : total =         0 Bytes sent 
 UDP Socket  4 : total =         0 Bytes received 
 TCP Socket  6 : total =    258616 Bytes sent 
 TCP Socket  6 : total =    283044 Bytes received 
 UDP Socket  4 : total =         0 Bytes sent 
 UDP Socket  4 : total =         0 Bytes received


Sinkronisasi waktu



Seperti praktik desain dan implementasi sistem simulasi terdistribusi telah menunjukkan, kesulitan terbesar disebabkan oleh masalah yang berkaitan dengan kontrol aliran waktu (sinkronisasi waktu).



Biasanya, ketika Anda mengatur bagaimana waktu gabungan disinkronkan, dua parameter ditetapkan, TimeRegulating dan TimeConstrained. Dalam praktiknya, mode-mode ini memengaruhi proses penerimaan pesan dari federasi lain dan secara langsung terkait dengan mekanisme pemesanan pesan:

  • dalam urutan penerimaan (pesan dikirimkan sesuai urutan penerimaannya tanpa kendali waktu);
  • priority (pesan masuk berada dalam antrian prioritas, cap waktu digunakan untuk menentukan prioritas pesan);
  • kausal (memastikan bahwa pesan dikirim ke federasi dengan urutan yang konsisten dengan kejadian sebelumnya dan berikutnya yang diwakili oleh pesan tersebut);
  • berdasarkan cap waktu (saat menggunakan layanan ini, pesan akan dikirim ke federasi sesuai urutan cap waktu mereka).


Perlu juga dicatat bahwa federasi yang berbeda dapat menggunakan metode sinkronisasi yang berbeda.



Pustaka perangkat lunak untuk implementasi RTI



Daftar implementasi HLA \ IEE1516 tersedia di en.wikipedia.org/wiki/Run-Time_Infrastructure . Saat ini, sejumlah besar implementasi tersedia, baik komersial maupun non-komersial. Sebagian besar implementasi dibuat dalam JAVA dan C ++ (ini adalah bahasa yang digunakan dalam standar), tetapi ada juga implementasi untuk MatLab, Python (proyek CERTI), dll.



Ketika memilih perpustakaan, perhatian khusus harus diberikan pada "sertifikasi" untuk mendukung IEEE 1516. Sebagai aturan , semua implementasi komersial memiliki "sertifikat", yang gratis tidak (banyak implementasi gratis sedang mempersiapkan sertifikasi semacam itu).



Tabel Penjualan Komersial:





Tabel penjualan non-komersial:





Saya pribadi menggunakan proyek ONERA CERTI (https://savannah.nongnu.org/projects/certi) untuk mendukung infrastruktur aplikasi yang didistribusikan.



Pengukuran kecepatan interaksi federasi melalui RTI



Tes tersebut sangat penting dalam desain sistem simulasi terdistribusi, terutama jika federasi yang berbeda terletak di jaringan komputer yang berbeda, dan bahkan lebih penting ketika berinteraksi dengan federasi melalui Internet.



Untuk mencapai penundaan waktu minimum, Anda harus memilih server dengan penundaan waktu transit paket terendah (Anda dapat memeriksa menggunakan perintah ping). Sebagai contoh, mari kita perhatikan pekerjaan salah satu sistem terdistribusi yang dibuat di NII EOR TyumGNGU. Jaringan 100 megabit digunakan (penundaan ping <0,231 ms), tidak ada sinkronisasi waktu (untuk mengurangi keterlambatan di dalam RTI), 2 komputer, server (rtig) sedang berjalan di salah satu mesin. Parameter Federasi - 2 objek berisi 5 atribut (satu objek per federasi / komputer), interaksi antara federasi adalah dua arah. Sebagai hasil dari pemrosesan pengukuran, ketergantungan jumlah interaksi per detik pada ukuran data yang dikirimkan diperoleh.



Hasil pengukuran tersebut memungkinkan kita untuk menarik banyak kesimpulan, misalnya, jika simulator harus bekerja dalam "waktu nyata" yang diberikan, mis. memperbarui, misalnya, setidaknya 60 kali per detik, maka untuk satu interaksi (untuk Fast Ethernet) tidak lebih dari 300 kilobyte harus ditransmisikan (jika, misalnya, 5 atribut, kemudian masing-masing 60 kilobyte). Pada saat yang sama, 300 kilobyte data yang ditransmisikan 60 kali per detik juga menunjukkan kemungkinan menggunakan RTI untuk mentransfer data suara dan video antara simulator, serta untuk berinteraksi dengan perangkat VR.



Ketika federasi melalui Internet, latensi minimum sebagian besar ditentukan oleh keterlambatan pengiriman paket. Misalnya, jika latensi paket antara server dan simulator adalah 300 ms, maka jumlah maksimum interaksi per detik tidak akan melebihi 3.



Penggunaan solusi yang lebih cepat seperti IpoIB (IP over InfiniBand, RFC 4392), 10G Ethernet, Myrinet-10G, dll. akan memungkinkan untuk meningkatkan throughput dan secara signifikan mengurangi latensi (solusi yang ada memungkinkan menghasilkan 30 juta interaksi per detik atau lebih).



Interaksi dengan sistem nyata



Tidak hanya model matematis objek, yaitu, sistem buatan, tetapi juga sistem dan perangkat nyata dapat bertindak sebagai federasi. Contohnya termasuk:



  • mikrofon yang menyediakan data audio;
  • kamera video yang menyediakan data video;
  • berbagai perangkat input / output seperti joystick (gambar), printer, dll.
  • berbagai sensor dan mekanisme kontrol yang terhubung ke komputer melalui papan ADC / DAC;
  • peralatan nyata dan sistem SCADA (Gambar 2.10.1., Bab 1.4.1.) melalui antarmuka OPC industri;
  • Antarmuka ke "desktop" dari sistem operasi nyata yang berjalan pada komputer atau mesin virtual yang terpisah (gambar);
  • Perangkat VR (bab 4.5.9.);
  • Antarmuka basis data, dll.


Kemungkinan seperti itu sangat menarik bagi simulator dan sistem simulasi secara umum.


More articles:


All Articles