Solusi IIoT | 6 Solusi Komunikasi IoT Industri

Untuk mengatakan bahwa tugas memilih IoT Industri Anda (IIoT ) infrastruktur komunikasi adalah usaha yang sangat kompleks akan meremehkan. Evaluasi berbagai solusi yang tersedia secara komersial memakan waktu dan mahal. Coba unduh dan evaluasi beberapa solusi dari setiap jenis infrastruktur dan Anda akan segera menemukan diri Anda di tengah-tengah proyek yang akan membutuhkan waktu enam bulan untuk diselesaikan oleh beberapa insinyur. Kita semua pernah ke sana, dan saya ingin membantu Anda menghemat waktu Anda yang berharga!

Tujuan dari posting ini adalah untuk memperkenalkan solusi infrastruktur IIoT populer yang tersedia secara komersial - AMQP, CoAP, DDS, RTI Connext DDS, MQTT, dan ZeroMQ - dan untuk menyoroti kemampuan setiap solusi. Enam bidang evaluasi berikut akan diterapkan:Arsitektur, Pola Komunikasi, Transportasi, Tipe &Penyaringan Data, Kualitas Layanan dan Keamanan.

Klik di sini untuk mengunduh versi PDF yang dapat dicetak.

1. Arsitektur

Tergantung pada pola arsitektur infrastruktur komunikasi yang diberikan, koneksi logis (diilustrasikan pada Gambar 1, di bawah) aplikasi akan digunakan untuk berkomunikasi dengan aplikasi lain di seluruh infrastruktur bervariasi. Dua arsitektur paling dasar yang digunakan dalam solusi middleware saat ini adalah (1) peer-to-peer dan (2) arsitektur bintang berbasis broker.

1. Arsitektur peer-to-peer memungkinkan aplikasi untuk berkomunikasi secara langsung satu sama lain tanpa harus mengirim data ke elemen perantara. Arsitektur ini secara inheren lebih efisien dalam pengiriman data karena hanya aplikasi pengirim dan penerima yang menghabiskan sumber daya CPU untuk menyelesaikan transfer. Oleh karena itu hanya aplikasi yang memiliki data dan aplikasi yang membutuhkan data yang akan menggunakan siklus CPU; sehingga menghasilkan distribusi pemrosesan yang efisien berdasarkan persyaratan aplikasi. Manfaat lain untuk arsitektur peer-to-peer adalah pengiriman data deterministik jauh lebih dapat dicapai karena tidak ada “Manusia Tengah” yang menangani data antara aplikasi produsen dan konsumen.

Gambar 1. Diagram arsitektur untuk berbagai protokol IoT.

2. Solusi berbasis pialang mengharuskan semua aplikasi yang mengirim data untuk mentransfer data langsung ke server broker, setelah itu akan berbalik dan mengirim ulang data ini ke aplikasi penerima. Manfaat dari arsitektur ini adalah bahwa broker mengelola semua kerumitan yang berkaitan dengan pengiriman/penerimaan data. Biasanya solusi ini memiliki alat bawaan untuk melihat dengan tepat jalur data mana yang aktif, siapa yang mengirim data, dan siapa yang menerima data. Solusi berbasis broker memang memperkenalkan latensi pada pengiriman data dan juga menghadirkan satu titik kegagalan sehingga jika broker gagal, semua komunikasi juga gagal. Untuk mengatasi masalah titik tunggal kegagalan, sebagian besar implementasi ini menyediakan server broker yang redundan dan sangat tersedia.

2. Pola Komunikasi

Dukungan pola komunikasi sangat penting untuk infrastruktur yang dapat Anda gunakan sepanjang siklus proyek atau lini produk Anda. Proyek awal mungkin hanya memerlukan publikasi/langganan, tetapi proyek atau produk berikutnya mungkin memerlukan pola tambahan seperti permintaan/balasan atau antrian. Dalam aspek ini, tidak semua solusi IoT yang ada saat ini dapat mendukung semua pola yang diperlukan untuk proyek Anda. Untuk tabel perbandingan, kami telah mengidentifikasi pola yang paling umum digunakan saat ini dan apakah setiap solusi infrastruktur menyediakan pola tersebut. Ini adalah pola yang paling umum digunakan saat ini:

• Terbitkan / Berlangganan :Aplikasi (pelanggan) meminta data 1 kali dan kemudian semua pembaruan data selanjutnya "Didorong" ke pelanggan. Tidak perlu meminta pembaruan data terus menerus.
• Permintaan/Balasan/RPC (Panggilan Prosedur Jarak Jauh ):Aplikasi pemohon mengirimkan permintaan, dan aplikasi pengirim membalas permintaan tersebut.
• Antri (atau Titik-ke-Titik ):Data didorong ke server yang akan menyimpan informasi dalam Antrian. Data kemudian dapat ditarik dari antrian atau didorong ke konsumen. Tidak seperti di Publish/Subscribe, setiap bagian data hanya didistribusikan ke satu aplikasi penerima.
• Satu ke Banyak :Kemampuan agar banyak aplikasi penerima mendapatkan data yang sama dari satu sumber.
• Banyak ke Satu :Kemampuan untuk menerima data dari banyak sumber ke dalam satu aplikasi konsumsi.

3. Transportasi &Perutean/Jembatan

Sebagian besar solusi middleware komunikasi mendukung TCP sebagai protokol komunikasi utama mereka. Menggunakan TCP memberi Anda pengiriman data yang andal menggunakan mekanisme keandalan bawaan yang melekat pada TCP. Ini bisa ideal untuk aliran data spesifik yang membutuhkan keandalan tetapi berlebihan dan menambahkan overhead yang tidak perlu ke data sensor sederhana yang tidak memerlukan pengiriman yang andal. Beberapa solusi IoT seperti ZeroMQ dan DDS juga mendukung transportasi lain seperti memori bersama. Salah satu transportasi yang perlu diperhatikan adalah penggunaan transportasi UDP untuk DDS. Karena implementasi keandalan sudah terintegrasi dengan DDS, maka tidak memerlukan transportasi yang andal di bawahnya. Hal ini memungkinkan aplikasi untuk memilih dan memilih aliran data mana yang pengirimannya andal dan aliran mana yang merupakan upaya terbaik.

Perutean data antara transportasi dan melintasi WAN adalah sesuatu yang disediakan oleh semua solusi ini dalam beberapa cara atau lainnya. Di dunia saat ini di mana sistem perusahaan, yang memanfaatkan teknologi ESB dan Web, juga harus mengakses beberapa data waktu nyata, middleware komunikasi juga penting untuk mendukung koneksi ke teknologi ini. Karena itu, Anda akan melihat perutean dan jembatan sebagai komponen inti untuk middleware sistem terdistribusi.

4. Jenis &Pemfilteran Data

Cara data dienkapsulasi dan direpresentasikan pada kabel juga unik untuk infrastruktur yang diberikan. Beberapa solusi hanya mengirim seluruh byte data mentah, dan terserah aplikasi untuk membuat serial dan deserialize data. Yang lain hanya mengirim data teks/string sehingga informasi tersebut dapat direpresentasikan dalam format XML atau JSON. Skenario ini sangat umum dalam teknologi web saat ini, tetapi bisa sangat tidak efisien karena dengan setiap pengiriman data paket juga berisi deskripsi data, terkadang membuat ukuran paket lebih dari 3x ukuran aslinya. Ukuran paket yang lebih besar meningkatkan penggunaan bandwidth serta meningkatkan penggunaan CPU pada sisi pengiriman dan penerimaan transfer. Tempatkan broker di tengahnya dan sekarang Anda juga menggandakan jumlah paket yang dikirimkan.

Solusi lain, seperti DDS, memungkinkan penggunaan data yang diketik kuat yang secara unik diserialisasikan dan dideserialisasi oleh middleware. Skema dikirim secara terpisah, yang tidak demikian halnya dengan XML atau JSON, dan oleh karena itu Anda tidak membayar penalti per pesan (atau sampel). Ini juga menjadi sangat penting untuk aspek penyaringan juga. Katakanlah Anda menyiapkan satu penerbit dengan banyak pelanggan. Beberapa pelanggan mungkin menginginkan semua data tetapi beberapa pelanggan hanya menginginkan sebagian dari data. Tanpa memiliki solusi data yang diketik dengan kuat, aplikasi Anda harus mengelola semua fungsi pemfilteran ini, yang merupakan lebih banyak kode yang harus Anda tulis. Dengan solusi seperti DDS di mana informasi jenis sangat ditentukan, middleware dapat mengatur semua pemfilteran untuk Anda. Lebih sedikit kode =pengembang yang lebih bahagia :). Faktanya, RTI Connext DDS memiliki fungsionalitas tambahan untuk menyediakan pemfilteran ini di sisi penulis transfer data, sehingga menghasilkan lebih sedikit penggunaan bandwidth pada kabel dan lebih sedikit pemrosesan CPU pada aplikasi yang tidak memerlukan data yang difilter.

5. Kualitas Layanan

Tidak semua data dibuat sama. Apa artinya ini? Nah, beberapa data dalam aplikasi terdistribusi real-time adalah data sensor streaming. Sebagian besar waktu data semacam ini tidak perlu dijamin pengiriman datanya. Untuk sensor tertentu, Anda mungkin hanya peduli bahwa tenggat waktu yang diberikan untuk pengiriman data telah terpenuhi atau yang lebih penting, tidak terpenuhi. Data lain mungkin data Alarm / Event. Data ini tidak memiliki periodisitas terhadap frekuensi ketersediaannya. Namun, menjamin pengirimannya sangat penting. Juga penting untuk data Alarm / Event adalah pengetahuan apakah sumber data itu hidup atau tidak. Jika produsen alarm tidak hidup, ini dapat menyebabkan peristiwa bencana dalam sistem waktu nyata Anda. Ini hanyalah beberapa aspek Quality of Service (QoS) yang mengatur berbagai aliran data aplikasi Anda. Kualitas Layanan adalah

[1] [2] 下一页