MQTT adalah protokol pesan publish/subscribe yang ringan dan telah menjadi transport default untuk mengirim data lapangan dari perangkat di lantai pabrik ke dashboard, historian, dan sistem SCADA. Alih-alih setiap klien melakukan polling ke setiap perangkat, sensor dan gateway mem-publish hasil pembacaan ke topic bernama pada sebuah broker pusat, dan sejumlah konsumen men-subscribe topic yang mereka butuhkan. Pemisahan (decoupling) ini, ditambah jaminan pengiriman yang dapat diatur dan jejak wire yang sangat kecil, adalah alasan MQTT 3.1.1 dan MQTT 5.0 kini menjadi standar dalam arsitektur industrial IoT (IIoT).
Model broker dan klien
MQTT memiliki tepat dua peran. Broker (Mosquitto, EMQX, HiveMQ, atau layanan cloud) adalah router pesan pusat. Klien adalah segala sesuatu yang lain: gateway Modbus-to-MQTT, PLC dengan stack MQTT native, node SCADA, historian, atau dashboard mobile. Sebuah klien tidak pernah berkomunikasi langsung dengan klien lain. Ia hanya membuka koneksi TCP ke broker, lalu melakukan publish dan subscribe. Broker mencocokkan setiap pesan yang dipublish dengan filter subscription dari semua klien yang terhubung dan meneruskan salinannya sesuai kebutuhan.
Topologi bintang inilah yang membuat MQTT mampu menskala. Menambahkan dashboard baru tidak memerlukan perubahan pada satu pun perangkat lapangan. Klien baru cukup men-subscribe topic yang relevan, dan broker menangani fan-out. Dalam deployment SURIOTA yang umum, sebuah gateway Modbus-to-MQTT SRT-MGATE-1210 membaca register RS-485 dari meter dan sensor, lalu mem-publish ulang setiap nilai sebagai pesan MQTT, mengubah peralatan serial lawas menjadi publisher di jaringan.
Merancang hierarki topic
Topic adalah string UTF-8 yang dibagi menjadi beberapa level oleh garis miring (forward slash), misalnya plant1/utilities/line3/meter07/power_kw. Tidak ada skema terpusat. Hierarki ini adalah konvensi yang Anda tetapkan sendiri, sehingga merancangnya dengan benar sejak awal akan menghindarkan dari migrasi yang menyakitkan kemudian. Skema IIoT yang kokoh bergerak dari yang luas ke yang spesifik: site / area / line / device / metric.
- site: identifier pabrik atau lokasi fisik (plant1, jakarta_dc).
- area: area proses atau zona bangunan (utilities, packaging, compressor_room).
- line: lini produksi atau feeder (line3, feeder_a).
- device: aset spesifik, idealnya terkait dengan nomor seri atau asset tag (meter07, pump_p101).
- metric: pengukuran individual (power_kw, temp_c, status, vibration_mm_s).
Pertahankan level dalam huruf kecil, hindari spasi, dan jangan pernah menempatkan garis miring di awal (level pertama yang kosong sebenarnya legal tetapi mubazir). Jangan meng-encode nilai yang berubah-ubah (seperti setpoint) ke dalam nama topic itu sendiri; topic mengidentifikasi apa sebuah pesan itu, sedangkan payload membawa nilainya. Banyak tim mengadopsi spesifikasi Sparkplug B, yang menstandarkan namespace topic (group/edge_node/device) dan encoding payload di atas MQTT justru karena alasan ini.
Wildcard untuk subscription
Publisher selalu menggunakan topic yang ditentukan sepenuhnya. Subscriber boleh menggunakan dua karakter wildcard. Wildcard satu level + mencocokkan tepat satu level: plant1/+/+/+/power_kw mengembalikan daya dari setiap perangkat di pabrik. Wildcard multi-level # mencocokkan semua yang berada di bawah suatu titik dan harus menjadi karakter terakhir: plant1/utilities/# mengirimkan setiap metrik dari area utilities. Sebuah historian SCADA mungkin men-subscribe plant1/# untuk menangkap seluruh data, sementara dashboard satu layar hanya men-subscribe segelintir topic yang ia tampilkan.
Quality of Service: QoS 0, 1, dan 2
QoS menetapkan jaminan pengiriman untuk setiap pesan yang dipublish dan setiap subscription. QoS dipilih secara independen pada sisi publish dan sisi subscribe; QoS efektif untuk pengiriman ke subscriber adalah yang lebih rendah di antara keduanya. Pertukarannya (trade-off) adalah keandalan versus latensi, bandwidth, dan beban broker.
| QoS | Nama | Handshake | Jaminan pengiriman | Mungkin duplikat? | Paling cocok untuk |
|---|---|---|---|---|---|
| 0 | At most once | PUBLISH (fire and forget) | Tidak ada; pesan bisa hilang jika link terputus | Tidak | Telemetri laju tinggi non-kritis yang sampel berikutnya segera tiba (tren temperatur, stream getaran) |
| 1 | At least once | PUBLISH lalu PUBACK | Pengiriman terjamin, tetapi bisa tiba lebih dari sekali | Ya; konsumen harus idempoten | Sebagian besar update tag SCADA, counter energi, alarm yang duplikatnya tidak berbahaya |
| 2 | Exactly once | PUBLISH, PUBREC, PUBREL, PUBCOMP (4 arah) | Terjamin tepat satu kali pengiriman | Tidak | Perintah kritis, pembacaan meter berkelas billing, totaliser yang penghitungan gandanya tidak dapat diterima |
Panduan praktis: jangan menjadikan QoS 2 sebagai default untuk segalanya. Handshake empat pesan kurang-lebih melipatempatkan trafik broker per pesan dan menambah latensi round-trip, yang berdampak pada backhaul seluler atau LoRa yang terbatas. Untuk sebagian besar telemetri pabrik, QoS 1 dengan konsumen yang idempoten adalah titik optimalnya. Cadangkan QoS 2 untuk control write dan untuk counter yang benar-benar membutuhkan semantik exactly-once, seperti Modbus power meter berkelas revenue yang memasok data ke sistem billing.
Retained message
Secara default, subscriber hanya menerima pesan yang dipublish setelah ia terhubung. Jika sebuah topic yang berubah lambat seperti plant1/utilities/line3/pump_p101/status hanya mem-publish saat state benar-benar berubah, maka dashboard yang terhubung di tengah shift tidak akan menampilkan apa pun sampai perubahan berikutnya. Mengaktifkan flag retain memberitahu broker untuk menyimpan pesan terakhir pada topic tersebut dan langsung mengirimkannya ke setiap subscriber baru. Hanya ada tepat satu retained message per topic; setiap publish retained yang baru menimpa yang sebelumnya. Untuk menghapusnya, publish-lah payload berukuran nol dengan flag retain aktif.
Gunakan retain untuk state nilai terakhir yang diketahui (status peralatan, setpoint, konfigurasi) agar setiap klien baru memperoleh snapshot instan. Jangan me-retain telemetri streaming berfrekuensi tinggi, atau subscriber baru akan menerima pembacaan basi yang terlihat seakan-akan masih terkini.
Last Will and Testament, keepalive
Ketika sebuah klien terhubung, ia dapat mendaftarkan Last Will and Testament (LWT): sebuah topic, payload, dan QoS yang akan dipublish broker secara otomatis jika klien tersebut terputus secara tidak normal. Sebuah gateway mungkin menetapkan LWT bernilai offline pada plant1/utilities/gateway01/state, dan mem-publish online (retained) sendiri saat terkoneksi. Kini setiap konsumen dapat langsung mengetahui apakah gateway masih hidup, yang merupakan hal esensial bagi status SCADA yang tepercaya.
Broker mendeteksi klien yang mati menggunakan interval keepalive yang dinegosiasikan saat connect. Jika tidak ada paket (bahkan PINGREQ sekalipun) yang tiba dalam 1,5x periode keepalive, broker menganggap klien telah hilang dan memicu LWT-nya. Pengaturan yang umum adalah 60 detik, memberi waktu kira-kira 90 detik untuk menyatakan klien offline. Keepalive yang lebih pendek mendeteksi kegagalan lebih cepat tetapi menambah trafik ping idle, yang berdampak pada link berbayar per pemakaian.
Keamanan: TLS dan autentikasi
Secara default MQTT berjalan di atas TCP polos pada port 1883, yang mengirimkan kredensial dan payload dalam teks terbuka. Untuk sistem IIoT produksi apa pun, jalankan MQTT di atas TLS pada port 8883. Ini mengenkripsi kanal dan, dengan sertifikat klien (mutual TLS), mengautentikasi setiap perangkat secara kriptografis. Minimal, aktifkan autentikasi username dan password serta nonaktifkan akses anonim pada broker. Tambahkan access control list (ACL) tingkat topic agar sebuah gateway hanya dapat mem-publish di bawah cabang site/area miliknya sendiri dan tidak dapat men-subscribe topic kontrol yang tidak ada urusannya untuk dibaca. Pertahanan berlapis (TLS untuk kanal, kredensial atau sertifikat untuk identitas, ACL untuk otorisasi) mencegah satu perangkat yang dikompromikan membuka seluruh pabrik.
MQTT versus OPC-UA
MQTT dan OPC-UA sering dibandingkan, tetapi keduanya menyelesaikan masalah yang berbeda. MQTT adalah pola transport dan messaging: ringan, berpusat pada broker, sangat baik untuk telemetri many-to-many di atas link WAN yang tidak andal, tetapi tidak membawa data model bawaan, sehingga makna terletak pada konvensi topic Anda atau pada overlay seperti Sparkplug B. OPC-UA adalah framework pemodelan informasi yang lengkap dengan node bertipe, address space yang dapat ditelusuri, dan keamanan yang kaya, secara tradisional client/server dan lebih berat di wire. Keduanya semakin sering hidup berdampingan: OPC-UA mendefinisikan model semantik di dalam pabrik sementara MQTT (atau OPC-UA PubSub di atas MQTT) menangani transport cloud yang efisien. Untuk pengumpulan data IIoT greenfield yang memasok analitik, MQTT plus namespace yang jelas biasanya adalah jalur yang lebih cepat; pilih OPC-UA bila interoperabilitas mendalam dan typing terstandar antar vendor otomasi menjadi prioritas.
Pertanyaan yang Sering Diajukan
Apakah MQTT cukup aman untuk kendali industri?
Protokolnya sendiri tidak memiliki keamanan wajib, sehingga keamanan menjadi tanggung jawab Anda. Dengan TLS pada port 8883, sertifikat klien atau kredensial yang kuat, ACL broker, dan broker yang di-harden, MQTT cocok untuk telemetri industri dan kendali supervisori. Hindari port 1883 polos dan akses anonim di lingkungan produksi.
Sebaiknya pakai QoS 1 atau QoS 2 untuk tag SCADA?
Gunakan QoS 1 untuk sebagian besar update tag dan buat konsumen Anda idempoten agar duplikat yang sesekali muncul tidak berbahaya. Cadangkan QoS 2 untuk perintah kontrol dan counter eksak (seperti total energi berkelas billing) yang pengiriman gandanya akan merusak hasil. QoS 2 memakan trafik broker dan latensi yang jauh lebih besar.
Bagaimana perbandingan MQTT dengan arsitektur polling Modbus?
Modbus bersifat request/response dan dikendalikan master; sebuah master SCADA harus melakukan polling ke setiap slave pada siklus tetap. MQTT bersifat report-by-exception dan dikendalikan publisher, sehingga perangkat mengirim data hanya saat data berubah atau pada interval yang dipilih, memangkas bandwidth dan meningkatkan skalabilitas. Dalam praktiknya, sebuah gateway Modbus-to-MQTT menjembatani kedua dunia, melakukan polling perangkat serial secara lokal dan mem-publish hasilnya ke hulu.
Apakah saya butuh perangkat edge untuk memakai MQTT?
Tidak selalu, tetapi sangat membantu. PLC dengan MQTT native dapat mem-publish secara langsung, namun sebagian besar peralatan terpasang berbicara Modbus atau fieldbus lain, sehingga diperlukan edge gateway untuk menerjemahkan dan menyangga (buffer) data. Memahami di mana logika tersebut sebaiknya ditempatkan dibahas dalam perbandingan kami antara edge gateway versus PLC versus RTU, dan data yang dipublish kemudian memasok dashboard serta analitik industri AI.
MQTT memberi imbalan atas beberapa keputusan baik yang dibuat sejak awal: namespace site/area/line/device/metric yang bersih, QoS yang dipilih per topic alih-alih secara global, retained last-known-value untuk state, LWT pada setiap gateway, serta TLS dengan ACL sejak hari pertama. Lakukan semua itu dengan benar dan Anda akan memiliki backbone telemetri yang menskala dari satu lini hingga seluruh pabrik. Untuk melihat bagaimana ini cocok dalam arsitektur sistem yang utuh, jelajahi layanan Internet of Things dari SURIOTA.