Databus vs. Database:6 Pertanyaan yang Harus Ditanyakan Setiap Pengembang IIoT

-sub sangat primitif. Aplikasi "mendaftarkan minat", dan kemudian semuanya dikirim ke aplikasi itu. Jadi, misalnya, algoritma deteksi tabrakan persimpangan bisa berlangganan "posisi kendaraan". Infrastruktur kemudian mengirimkan pesan dari sensor mana pun yang mampu menghasilkan posisi, tanpa mengetahui data di dalam pesan itu. Bahkan pub-sub "pemfilteran konten" hanya menawarkan spesifikasi yang sangat sederhana dan mengharuskan sistem untuk memilih terlebih dahulu apa yang penting untuk semua. Tidak ada kontrol aliran yang nyata.

Sebuah databus jauh lebih ekspresif. Persimpangan itu bisa mengatakan "Saya hanya tertarik pada posisi kendaraan dalam jarak 200m, bergerak dengan kecepatan 10m/s ke arah saya. Jika kendaraan jatuh ke dalam spesifikasi saya, saya perlu diperbarui 200 kali per detik. Anda (databus) perlu menjamin saya bahwa semua sensor yang memberi makan algoritme ini berjanji untuk mengirimkan data secepat itu...tidak lebih lambat atau lebih cepat. Jika sebuah sensor memperbarui 1000 kali per detik, maka hanya kirimkan saya setiap pembaruan ke-5. Saya juga perlu tahu bahwa Anda sebenarnya berhubungan dengan saat ini -sensor langsung (yang saya definisikan sebagai produksi dalam 0,01 detik terakhir) pada semua kemungkinan pendekatan jalan raya setiap saat. Setiap sensor harus dapat menyimpan 600 sampel lama (senilai 3 detik), dan memperbarui saya dengan data lama itu jika saya perlu dia." (Ini adalah beberapa dari 20+ pengaturan QoS dalam standar DDS.)

Perhatikan bahwa aplikasi berlangganan dalam kasus pub-sub primitif sangat bergantung pada properti sebenarnya dari produsennya. Entah bagaimana ia harus percaya bahwa mereka hidup (!), bahwa mereka memiliki cukup buffer untuk menyimpan informasi yang mungkin diperlukan, bahwa mereka tidak akan membanjirinya dengan informasi atau memberikannya terlalu lambat. Jika ada 10.000 mobil yang terindra 1000x/detik, tetapi hanya 3 dalam jarak 200m, ia harus menerima 10.000*1000 =10m sampel setiap detik hanya untuk menemukan 3*200 =600 yang perlu diperhatikan. Itu harus melakukan ping ke setiap sensor 100x/detik hanya untuk memastikannya aktif. Jika ada sensor redundan di jalur yang berbeda, itu harus melakukan ping semuanya secara independen dan entah bagaimana memastikan semua jalur tertutup. Jika ada banyak aplikasi, mereka semua harus melakukan ping ke semua sensor secara mandiri. Itu juga harus mengetahui skema dari produsen, dll.

Aplikasi dalam kasus kedua akan, sebaliknya, menerima persis 600 sampel yang diperhatikannya, nyaman karena mengetahui bahwa setidaknya satu sensor untuk setiap jalur aktif. Kecepatan aliran dijamin. Keandalan yang memadai dijamin. Total aliran data berkurang 99,994% (kami hanya membutuhkan 600/10m sampel, dan middleware pintar memfilter pada sumbernya). Untuk kelengkapan, perhatikan bahwa algoritma tumbukan benar-benar independen dari sensor itu sendiri. Ini dapat digunakan kembali di persimpangan lain, dan akan bekerja dengan satu sensor per jalur atau 17. Jika selama runtime, jaringan terlalu dimuat untuk memenuhi spesifikasi data (atau ada yang gagal), aplikasi akan segera diberi tahu.

Pertanyaan 5:Bagaimana databus berbeda dari mesin CEP?

Jawaban singkat:databus adalah konsep terdistribusi mendasar yang memilih dan mengirimkan data dari produsen lokal yang sesuai dengan spesifikasi sederhana. Mesin CEP adalah layanan terpusat yang dapat dijalankan yang mampu melakukan spesifikasi yang jauh lebih kompleks, tetapi harus memiliki semua aliran data yang dikirim ke satu tempat.

Jawaban panjang:Mesin Pemrosesan Peristiwa Kompleks (CEP) memeriksa aliran data yang masuk, mencari pola yang Anda programkan untuk diidentifikasi. Ketika menemukan salah satu pola tersebut, Anda dapat memprogramnya untuk mengambil tindakan. Pola dapat berupa kombinasi kompleks dari data masa lalu dan data masa depan yang masuk. Namun, ini adalah layanan tunggal, berjalan pada satu CPU di suatu tempat. Itu tidak mengirimkan informasi.

Sebuah databus juga mencari pola data. Namun, spesifikasinya lebih sederhana; itu membuat keputusan tentang setiap item data seperti yang dihasilkan. Tindakannya juga lebih sederhana; satu-satunya tindakan yang mungkin dilakukan adalah mengirimkan data tersebut ke pemohon. Kekuatan databus adalah bahwa ia didistribusikan secara fundamental. Pencarian terjadi secara lokal pada ratusan, ribuan, atau bahkan jutaan node yang berpotensi. Dengan demikian, databus adalah cara yang sangat ampuh untuk memilih data yang tepat dari sumber yang tepat dan mengirimkannya ke tempat yang tepat. Databus adalah semacam set mesin CEP yang terdistribusi, satu untuk setiap sumber informasi yang mungkin, yang secara otomatis diprogram oleh pengguna informasi tersebut. Tentu saja, databus memiliki banyak properti lain di luar pencocokan pola, seperti mediasi skema, manajemen redundansi, dukungan transportasi, protokol yang dapat dioperasikan, dll.

Pertanyaan 6:Aplikasi apa yang mendorong standar DDS dan databus?

Aplikasi awal dalam robot cerdas, "keunggulan informasi", dan sistem terkoordinasi besar seperti manajemen tempur angkatan laut. Sistem ini membutuhkan keandalan bahkan ketika komponen gagal, data cukup cepat untuk mengontrol proses fisik, dan penemuan selektif dan pengiriman ke skala. Sentrisitas data benar-benar menyederhanakan kode aplikasi dan antarmuka yang terkontrol, memungkinkan tim pemrogram bekerja pada sistem perangkat lunak besar dari waktu ke waktu. Standar DDS adalah keluarga standar yang aktif dan berkembang yang awalnya didorong oleh vendor dan pelanggan. Ini memiliki penggunaan yang signifikan di banyak vertikal, termasuk medis, transportasi, kota pintar, dan energi.

Jika Anda ingin mempelajari tentang bagaimana perangkat lunak cerdas menyapu IIoT, pastikan untuk mengunduh whitepaper kami tentang masa depan industri otomotif, "Rahasia Saus Otonom Mobil."