OPC UA vs MQTT: kenapa pabrik modern justru menggunakan keduanya
OPC UA membawa model informasi lengkap, dengan struktur dan makna datanya. MQTT menyediakan cara kirim pesan yang ringan dan efisien. Keduanya tidak bersaing. Dalam praktiknya, sebagian besar pabrik modern justru memakai keduanya.
Perdebatan yang sebenarnya tidak perlu ada
OPC UA dan MQTT hampir selalu dibandingkan seolah keduanya bisa saling menggantikan.
Padahal keduanya menyelesaikan masalah yang berbeda.
OPC UA menjawab satu pertanyaan: apa arti data ini?
MQTT menjawab pertanyaan lain: bagaimana memindahkan data ini dengan efisien?
Perbedaannya sangat mendasar.
OPC UA tidak hanya mengirim nilai. Data yang diterima sudah lengkap dengan tipe data, satuan, timestamp, status kualitas, dan hubungannya dengan objek lain dalam sebuah model informasi.
MQTT lain lagi. Protokol ini hanya bertugas mengirim pesan dari satu titik ke titik lain dengan publish-subscribe yang sangat ringan.
Isi pesannya bisa berupa apa saja.
Begitu bedanya dipahami, istilah “versus” jadi kurang relevan.
Dalam praktiknya, sebagian besar pabrik justru memakai keduanya sekaligus.
Yang dibawa masing-masing
| OPC UA | MQTT | |
|---|---|---|
| Standar | IEC 62541 | OASIS |
| Model komunikasi | Client/server dan publish-subscribe | Publish-subscribe melalui broker |
| Makna data | Didefinisikan oleh model informasi | Tidak ditentukan |
| Discovery | Tersedia melalui address space | Tidak tersedia |
| Keamanan | Menjadi bagian dari spesifikasi | Bergantung pada TLS dan broker |
| Overhead | Lebih tinggi | Sangat rendah |
| Lingkungan yang cocok | Jaringan pabrik yang stabil | Jaringan dengan keterbatasan bandwidth |
| Implementasi yang umum | PLC, mesin, dan equipment proses | Sensor, perangkat edge, dan koneksi jarak jauh |
Beda yang paling penting ada pada cara keduanya memperlakukan data.
Dengan OPC UA, sebuah aplikasi bisa terhubung ke equipment yang belum pernah dikenalnya, menelusuri seluruh struktur datanya, lalu memahami arti setiap nilainya.
Dengan MQTT, aplikasi hanya menerima pesan dari sebuah topic.
Arti pesannya harus sudah diketahui sebelumnya.
Ini bukan kelemahan MQTT.
Justru kesederhanaan inilah yang membuat MQTT sangat ringan, fleksibel, dan efisien.
Kenapa Sparkplug B muncul
Karena MQTT sengaja dibuat sederhana, komunitas industri mulai membangun aturan tambahan di atasnya.
Mereka butuh jawaban untuk pertanyaan yang sama.
Bagaimana sebuah topic harus diberi nama?
Bagaimana cara mengetahui apakah sebuah perangkat masih aktif?
Bagaimana sebuah nilai harus direpresentasikan?
Tanpa standar tambahan, setiap organisasi membuat aturannya sendiri.
Akibatnya, integrasi sulit dipindahkan dari satu lingkungan ke lingkungan lain.
Sparkplug B hadir untuk menyelesaikan masalah itu.
Spesifikasi ini mendefinisikan struktur payload, pola penamaan topic, serta mekanisme birth dan death, jadi sistem tahu kapan sebuah perangkat terhubung atau terputus.
Menariknya, perkembangan ini membuat kedua protokol makin mirip.
OPC UA menambahkan dukungan publish-subscribe.
MQTT mendapat lapisan struktur lewat Sparkplug B.
Batas keduanya kini jauh lebih tipis daripada beberapa tahun lalu.
Tidak semua equipment harus memakai protokol yang sama
Banyak perusahaan mencoba menetapkan satu protokol sebagai standar seluruh pabrik.
Cara ini jarang berhasil.
Yang lebih realistis adalah menilai setiap koneksi secara terpisah.
OPC UA biasanya pilihan yang tepat kalau:
- Equipment sudah mendukung OPC UA.
- Tipe data dan satuan harus dipertahankan.
- Model informasi diperlukan.
- Jaringan produksi relatif stabil.
MQTT biasanya lebih cocok kalau:
- Perangkat memiliki keterbatasan sumber daya.
- Sensor tersebar di banyak lokasi.
- Koneksinya lewat jaringan seluler.
- Latensi tinggi dan gangguan koneksi sulit dihindari.
Bagaimana dengan Modbus TCP?
Banyak equipment di lapangan masih memakainya.
Tidak ada model informasi.
Tidak ada discovery.
Register-nya dipetakan manual.
Namun Modbus tetap sangat relevan.
Satu register untuk status jalan atau berhenti, ditambah satu register penghitung produksi, sudah cukup untuk menghitung availability dan mendeteksi downtime.
Di banyak pabrik, terutama di Indonesia, Modbus masih protokol yang paling sering ditemui.
Mengabaikannya hanya karena dianggap kuno sering berarti membiarkan sebagian equipment tetap terisolasi.
Setiap lapisan integrasi ada harganya
Arsitektur modern hampir selalu menambahkan satu atau beberapa lapisan di antara equipment dan aplikasi.
Gateway menerjemahkan protokol.
Middleware menormalkan data.
Broker mendistribusikan pesan.
Sering kali, lapisan-lapisan ini memang perlu.
Namun setiap lapisan tambahan ada akibatnya.
Timestamp bisa berubah dari waktu kejadian menjadi waktu data diterima.
Status kualitas bisa hilang karena format perantaranya tidak mendukung.
Nilai bisa berubah karena agregasi atau resampling.
Yang paling berbahaya justru kegagalan yang tidak terlihat.
Gateway yang berhenti memperbarui data tetapi terus mengirim nilai terakhirnya akan terlihat seperti equipment yang berjalan normal.
Dashboard tetap bergerak.
OEE tetap dihitung.
Alarm tidak pernah muncul.
Padahal datanya sudah tidak menggambarkan kondisi sebenarnya.
Kesalahan seperti ini jauh lebih sulit dideteksi daripada koneksi yang benar-benar putus.
Karena itu, pertanyaan yang lebih penting saat menilai sebuah platform bukan protokol apa yang didukung, tetapi berapa banyak lapisan yang dilewati data sebelum akhirnya dipakai.
Makin sedikit perpindahan, makin kecil kemungkinan makna data berubah di tengah jalan.
Posisi VECHR MES
VECHR MES terhubung langsung lewat OPC UA, MQTT, dan Modbus TCP di level resource, tanpa perantara.
Equipment menjadi bagian dari model produksi, bukan objek yang ditempelkan lewat lapisan integrasi tambahan.
Nilai tag tidak hanya membawa angka, tetapi juga status kualitasnya.
Ini sangat penting saat data dipakai untuk menghitung OEE atau menganalisis downtime.
Nilai yang sudah tidak diperbarui bisa dibedakan dari nilai yang benar-benar valid.
Konektivitas, eksekusi produksi, dan analitik juga berjalan di platform yang sama.
Artinya, data tidak berhenti sebagai sekumpulan tag.
Setiap nilai langsung punya konteks.
Resource mana yang menghasilkannya.
Production order mana yang sedang berjalan.
Material apa yang sedang diproses.
Dan langkah produksi mana yang sedang berlangsung.
Konteks inilah yang mengubah data menjadi informasi yang benar-benar bisa dipakai untuk mengambil keputusan.
Pertanyaan yang Sering Diajukan
Apakah OPC UA dan MQTT bisa digunakan secara bersamaan?
Bisa, dan justru itu yang paling umum. OPC UA punya model publish-subscribe yang bisa berjalan di atas MQTT, jadi struktur data OPC UA bisa dikirim lewat MQTT. Banyak pabrik juga menjalankan keduanya berdampingan: OPC UA untuk PLC dan equipment, MQTT untuk sensor, perangkat edge, dan lokasi dengan jaringan yang tidak selalu stabil.
Mana yang lebih cocok untuk terhubung ke PLC?
Kalau PLC mendukung OPC UA, itu biasanya pilihan paling sederhana karena datanya sudah terstruktur. Untuk PLC yang hanya mendukung Modbus TCP, sering perlu gateway. Di titik itu, pertanyaannya bukan lagi protokol apa yang dipakai PLC, tetapi bagaimana data dari gateway diteruskan ke sistem lain.
Apa itu Sparkplug B dan apakah kami membutuhkannya?
Sparkplug B adalah spesifikasi yang menambahkan struktur ke MQTT. Isinya format payload, pola penamaan topic, dan cara mendeteksi apakah sebuah perangkat sedang aktif. Kalau MQTT dipakai untuk data industri, aturan seperti Sparkplug B hampir selalu perlu, supaya setiap sistem memahami data yang dipertukarkan dengan cara yang sama.
Apakah MQTT kurang aman dibandingkan OPC UA?
Tidak. Bedanya ada pada cara mengamankannya. OPC UA memasukkan autentikasi, enkripsi, dan penandatanganan data ke dalam spesifikasinya. MQTT mengandalkan TLS, autentikasi broker, dan kebijakan akses yang dikonfigurasi terpisah. Keduanya bisa diamankan dengan sangat baik kalau diterapkan dengan benar.
Apakah MES harus mendukung keduanya?
Yang terpenting bukan banyaknya protokol di brosur produk, tetapi apakah sistem bisa langsung terhubung ke equipment yang benar-benar dipakai di pabrik Anda. Makin banyak lapisan integrasi, makin besar risiko data terlambat, kehilangan konteks, atau berubah makna.