MQTT vs HTTP vs Modbus TCP vs OPC UA untuk Gateway IoT Industri

Data Sensor yang Sama Dapat Dikirimkan dengan Cara Berbeda

Sensor tidak menentukan cloud final atau protokol SCADA. RS485 Modbus RTU biasanya digunakan pada lapisan lapangan, sedangkan gateway menerjemahkan atau mengemas ulang data tersebut untuk lapisan aplikasi. Protokol upstream yang benar bergantung pada siapa yang memulai komunikasi, di mana data disimpan, apakah perintah harus dikembalikan ke perangkat, dan perangkat lunak apa yang sudah dioperasikan pelanggan.

MQTT: Terbaik untuk Sistem Publikasikan/Berlangganan Berorientasi Cloud

MQTT memisahkan pengirim dan penerima melalui broker. Gateway menerbitkan data sensor ke suatu topik, sementara satu atau lebih aplikasi berlangganan topik tersebut. Hal ini berguna untuk situs pemantauan terdistribusi karena gateway tidak perlu mengetahui setiap konsumen akhir data.

Konfigurasi MQTT yang benar biasanya mencakup alamat broker, port, ID klien, otentikasi, dan aturan topik. Kesalahan umum adalah berasumsi bahwa “perangkat online” berarti “data tiba”. Status koneksi MQTT hanya membuktikan bahwa sesi telah dibuat. Gateway mungkin masih menerbitkan topik yang salah, server mungkin berlangganan topik berbeda, atau lapisan akuisisi sensor mungkin tidak memiliki data yang valid.

Publikasikan dan Berlangganan Tidak Boleh Bingung

Topik publikasi adalah tempat perangkat mengirimkan telemetri. Topik berlangganan biasanya digunakan untuk perintah atau pesan yang dikirim dari platform kembali ke perangkat. Jika server ingin menerima pengukuran, server harus berlangganan topik publikasi gateway. Menggunakan topik terbitkan dan berlangganan yang sama dapat membuat loop yang tidak diinginkan dalam beberapa implementasi dan tidak boleh diperlakukan sebagai konfigurasi default.

MQTTS dan Pelabuhan 8883

MQTTS biasanya berarti MQTT melalui TLS. Port 8883 adalah port TLS yang umum, tetapi keberhasilan penggunaan tidak hanya bergantung pada nomor port. Pustaka TLS, metode validasi CA, sertifikat server, sertifikat klien opsional, dan versi MQTT harus kompatibel. Dalam pengujian cloud pihak ketiga yang sebenarnya, gateway terkadang dapat terhubung ke satu broker TLS tetapi gagal terhadap broker lain hingga firmware diperbarui.

Untuk proyek produksi, uji broker, mode sertifikat, dan firmware yang tepat sebelum mengirimkan dalam jumlah besar. Sertifikat harus berasal dari atau cocok dengan server pelanggan atau platform cloud; itu bukan file umum yang dapat diciptakan oleh produsen gateway secara independen dari server.

HTTP POST: Terbaik Saat Pelanggan Memiliki Titik Akhir Web

HTTP seringkali merupakan pilihan paling sederhana ketika pelanggan memiliki aplikasi server yang dapat menerima permintaan POST. Gateway dapat dikonfigurasi sebagai klien HTTP dan secara berkala mengirimkan JSON ke URL target. Ini cocok dengan backend web khusus dan lingkungan di mana tim perangkat lunak lebih memilih penanganan permintaan/respons langsung daripada mengoperasikan broker MQTT.

Payload tipikal dapat berisi stempel waktu, ID stasiun, dan objek params dengan nilai sensor. Nama bidang yang tepat adalah konvensi proyek. Langkah penting adalah menyetujui tipe data, unit, perilaku data yang hilang, dan respons server sebelum penerapan.

Modbus TCP: Terbaik Saat SCADA atau PLC Harus Melakukan Polling Data

Modbus TCP membawa model register Modbus yang sudah dikenal melalui Ethernet. Seringkali cocok bila sistem PLC, HMI atau SCADA sudah dirancang sebagai master Modbus. Gateway dapat menjembatani perangkat RS485 Modbus RTU ke sisi Ethernet atau mengekspos nilai yang dikumpulkan melalui peta register yang ditentukan.

Jika pelanggan mengatakan, "Beri kami alamat IP dan beri tahu kami di mana setiap sinyal disimpan; sistem kami akan membacanya," Modbus TCP biasanya lebih dekat dengan arsitektur yang diperlukan daripada MQTT atau HTTP.

OPC UA: Terbaik untuk Integrasi Industri yang Lebih Kaya

OPC UA banyak digunakan dalam perangkat lunak industri karena dapat menyajikan data sebagai tag atau node bernama dengan struktur dan metadata, bukan hanya alamat register numerik. Ini cocok untuk SCADA, middleware industri, dan aplikasi PC yang memerlukan penemuan standar dan perilaku berlangganan.

Tidak semua gateway mendukung OPC UA dalam peran yang sama, jadi pastikan apakah gateway berfungsi sebagai server OPC UA, klien, atau keduanya. Dalam proyek NiuBoL, edge gateway yang lebih mumpuni lebih disukai ketika OPC UA merupakan persyaratan inti.

Protokol Mana yang Harus Anda Pilih?

Tidak Mencampur Protokol Lapangan dan Protokol Hulu

Suatu sistem dapat menggunakan RS485 Modbus RTU dari sensor ke gateway dan MQTT dari gateway ke cloud secara bersamaan. Ia juga dapat menggunakan sensor 4–20mA ke dalam gateway ADC dan kemudian mengekspos nilai-nilai tersebut melalui Modbus TCP atau OPC UA. Antarmuka lapangan dan protokol aplikasi adalah lapisan desain yang terpisah.

Pemecahan Masalah: MQTT Terhubung tetapi Tidak Ada Data

1. Pastikan lapisan sensor benar-benar menghasilkan data di dalam gateway.
2. Periksa interval unggahan dan konfirmasikan gateway dipublikasikan, tidak hanya terhubung.
3. Verifikasi topik publikasi dengan tepat, termasuk garis miring di depan dan sensitivitas huruf besar/kecil di mana broker/platform memperlakukannya secara berbeda.
4. Gunakan klien MQTT independen untuk berlangganan topik yang sama dan mengisolasi gateway dari platform bisnis.
5. Periksa autentikasi, tabrakan ID klien, dan apakah klien lain menggunakan kredensial yang sama.
6. Untuk TLS, verifikasi kompatibilitas sertifikat CA/server dan pustaka firmware.
7. Gunakan log gateway dan, jika perlu, tangkapan jaringan untuk menentukan apakah paket meninggalkan perangkat dan bagaimana server merespons.

Pemecahan Masalah: Server HTTP Tidak Menerima Apa Pun

Akuisisi terpisah pertama dari unggahan. Jika log gateway mengatakan perangkat yang lebih rendah tidak merespons, perbaiki lapisan komunikasi sensor sebelum melakukan debug pada server. Kemudian verifikasi URL target, port, jangkauan DNS/jaringan, jenis konten, format JSON, dan persyaratan HTTPS. Fungsi gateway HTTP dalam arsitektur ini adalah klien yang aktif POST data; ini tidak secara otomatis merupakan server HTTP untuk dijelajahi pelanggan.

Pertanyaan Umum

Q1: Apakah MQTT lebih baik daripada HTTP untuk IoT?

A1: Tidak ada yang lebih baik secara universal. MQTT kuat untuk armada terbitkan/berlangganan; HTTP mudah digunakan ketika pelanggan sudah memiliki titik akhir penerimaan web.

Q2: Apakah MQTT “online” berarti platform telah menerima data sensor?

A2: Tidak. Status online hanya mengkonfirmasi koneksi. Topik, penerbitan, langganan, dan akuisisi sensor masih harus diverifikasi.

Q3: Apa perbedaan antara topik publikasi dan berlangganan MQTT?

A3: Publikasikan adalah tempat gateway mengirimkan telemetri; berlangganan adalah tempat gateway mendengarkan pesan atau perintah server-ke-perangkat.

Q4: Bisakah gateway IoT mengirim JSON melalui HTTP POST?

A4: Ya, pada gateway/firmware yang mendukung unggahan klien HTTP. Setujui struktur JSON yang tepat dan penanganan respons dengan tim server.

Q5: Apakah port 8883 selalu didukung untuk MQTTS?

A5: 8883 adalah hal yang umum, tetapi firmware gateway dan mode sertifikat TLS harus kompatibel dengan broker target. Pemeriksaan desain untuk integrasi sistem sensor: Catat rentang yang disepakati, respons alarm, pemeriksaan antarmuka, dan bukti pemeliharaan dalam berkas commissioning atau penerimaan.

Q6: Kapan saya harus menggunakan Modbus TCP dan bukan MQTT?

A6: Gunakan Modbus TCP ketika master industri seperti PLC atau SCADA harus secara aktif melakukan polling register melalui Ethernet.

Q7: Kapan OPC UA lebih disukai?

A7: Gunakan OPC UA ketika perangkat lunak industri mendapat manfaat dari tag/node terstandar, metadata, dan interoperabilitas yang lebih kaya.

Q8: Bisakah satu gateway menggunakan lebih dari satu protokol upstream?

A8: Banyak edge gateway yang bisa melakukannya, tetapi perilaku multi-tujuan secara simultan harus diverifikasi untuk firmware dan proyek yang tepat.

Ringkasan