OPC UA vs MQTT: kenapa pabrik modern justru menggunakan keduanya

Perdebatan yang sebenarnya tidak perlu ada

OPC UA dan MQTT hampir selalu dibandingkan seolah-olah keduanya merupakan dua teknologi yang saling menggantikan.

Padahal, keduanya dirancang untuk menyelesaikan masalah yang berbeda.

OPC UA menjawab satu pertanyaan: apa arti data ini?

MQTT menjawab pertanyaan yang lain: bagaimana cara memindahkan data ini secara efisien?

Perbedaannya sangat mendasar.

OPC UA tidak hanya mengirimkan sebuah nilai. Data yang diterima sudah dilengkapi dengan tipe data, satuan, timestamp, status kualitas, dan hubungan dengan objek lain di dalam sebuah model informasi.

MQTT mengambil pendekatan yang berbeda. Protokol ini hanya bertanggung jawab mengirimkan pesan dari satu titik ke titik lain menggunakan mekanisme publish-subscribe yang sangat ringan.

Isi pesannya bisa berupa apa saja.

Begitu perbedaannya dipahami, istilah “versus” sebenarnya menjadi kurang relevan.

Dalam praktiknya, sebagian besar pabrik justru menggunakan keduanya secara bersamaan.

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

Perbedaan yang paling penting ada pada cara kedua protokol memperlakukan data.

Dengan OPC UA, sebuah aplikasi dapat terhubung ke equipment yang belum pernah dikenalnya, menelusuri seluruh struktur datanya, lalu memahami arti setiap nilai yang tersedia.

Dengan MQTT, aplikasi hanya menerima pesan dari sebuah topic.

Makna dari pesan tersebut harus sudah diketahui sebelumnya.

Ini bukan kelemahan MQTT.

Justru kesederhanaan inilah yang membuat MQTT menjadi sangat ringan, fleksibel, dan efisien.

Kenapa Sparkplug B muncul

Karena MQTT sengaja dirancang agar tetap sederhana, komunitas industri mulai membangun aturan tambahan di atasnya.

Mereka membutuhkan 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 akan membuat konvensinya sendiri.

Akibatnya, integrasi menjadi sulit dipindahkan dari satu lingkungan ke lingkungan lain.

Sparkplug B hadir untuk menyelesaikan masalah tersebut.

Spesifikasi ini mendefinisikan struktur payload, pola penamaan topic, serta mekanisme birth dan death yang memungkinkan sistem mengetahui kapan sebuah perangkat terhubung atau terputus.

Menariknya, perkembangan ini membuat kedua protokol mulai saling mendekat.

OPC UA menambahkan dukungan publish-subscribe.

MQTT memperoleh lapisan struktur melalui Sparkplug B.

Batas di antara keduanya menjadi semakin tipis dibandingkan beberapa tahun yang lalu.

Tidak semua equipment harus menggunakan protokol yang sama

Banyak perusahaan mencoba menentukan satu protokol sebagai standar untuk seluruh pabrik.

Pendekatan seperti ini jarang berhasil.

Pilihan yang lebih realistis adalah mengevaluasi setiap koneksi secara terpisah.

OPC UA biasanya menjadi pilihan yang tepat ketika:

• Equipment sudah mendukung OPC UA.
• Tipe data dan satuan harus dipertahankan.
• Model informasi diperlukan.
• Jaringan produksi relatif stabil.

MQTT biasanya lebih cocok ketika:

• Perangkat memiliki keterbatasan sumber daya.
• Sensor tersebar di banyak lokasi.
• Koneksi menggunakan jaringan seluler.
• Latensi tinggi dan gangguan koneksi sulit dihindari.

Bagaimana dengan Modbus TCP?

Banyak equipment di lapangan masih menggunakannya.

Tidak ada model informasi.

Tidak ada discovery.

Pemetaan register dilakukan secara manual.

Namun, Modbus tetap sangat relevan.

Satu register yang dapat melaporkan status berjalan atau berhenti, ditambah satu register penghitung produksi, sudah cukup untuk menghitung availability dan mendeteksi downtime.

Di banyak pabrik, khususnya di Indonesia, Modbus masih menjadi protokol yang paling umum ditemukan.

Mengabaikannya hanya karena dianggap terlalu lama sering kali berarti membiarkan sebagian equipment tetap terisolasi.

Setiap lapisan integrasi memiliki biayanya sendiri

Arsitektur modern hampir selalu menambahkan satu atau beberapa lapisan di antara equipment dan aplikasi.

Gateway menerjemahkan protokol.

Middleware menormalkan data.

Broker mendistribusikan pesan.

Dalam banyak kasus, pendekatan ini memang diperlukan.

Namun, setiap lapisan tambahan membawa konsekuensi.

Timestamp dapat berubah dari waktu kejadian menjadi waktu penerimaan.

Status kualitas dapat hilang karena format perantara tidak mendukungnya.

Nilai dapat diubah melalui proses agregasi atau resampling.

Kondisi yang paling berbahaya justru ketika kegagalan tidak terlihat.

Gateway yang berhenti memperbarui data, tetapi terus mengirimkan nilai terakhirnya, akan terlihat seperti equipment yang beroperasi secara normal.

Dashboard tetap bergerak.

OEE tetap dihitung.

Alarm tidak pernah muncul.

Padahal data yang digunakan sudah tidak lagi merepresentasikan kondisi sebenarnya.

Kesalahan seperti ini jauh lebih sulit dideteksi dibandingkan koneksi yang benar-benar terputus.

Karena itu, pertanyaan yang lebih penting saat mengevaluasi sebuah platform bukanlah protokol apa yang didukung, melainkan berapa banyak lapisan yang harus dilalui data sebelum akhirnya digunakan.

Semakin sedikit perpindahan, semakin kecil kemungkinan makna data berubah di tengah perjalanan.

Posisi VECHR MES

VECHR MES terhubung secara native melalui OPC UA, MQTT, dan Modbus TCP langsung di level resource.

Equipment menjadi bagian dari model produksi, bukan objek yang ditempelkan melalui lapisan integrasi tambahan.

Nilai tag tidak hanya membawa angka, tetapi juga status kualitasnya.

Perbedaan ini sangat penting ketika data digunakan untuk menghitung OEE atau menganalisis downtime.

Nilai yang sudah tidak diperbarui dapat dibedakan dari nilai yang benar-benar valid.

Konektivitas, eksekusi produksi, dan analitik juga berjalan di dalam platform yang sama.

Artinya, data tidak berhenti sebagai sekumpulan tag.

Setiap nilai langsung memiliki 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 dapat digunakan untuk mengambil keputusan.