Mightyblue

Posted on Mar 7

Dari Shopfloor ke Cloud: Arsitektur IIoT dengan MQTT + OPC UA untuk Data Mesin Real-Time dan Aman

#iot #mqtt #opcua #indonesia

Di banyak pabrik, data mesin sudah ada—tapi tercecer di HMI, spreadsheet, atau terkunci di jaringan OT yang “tak boleh disentuh”. Padahal, tren secure connectivity di OT makin jadi perhatian serius: panduan terbaru tentang konektivitas OT menekankan desain koneksi yang aman, terkelola, dan tidak “asal tembus” ke internet (lihat ringkasan prinsipnya di artikel NCSC-led secure connectivity principles untuk OT). Di artikel ini, kita akan membedah cara membawa data shopfloor ke cloud tanpa mengorbankan keamanan, dengan pendekatan arsitektur iiot mqtt opcua.

Secara ilmiah, kombinasi MQTT dan OPC UA bukan sekadar “dua protokol keren”: riset terbaru membandingkan keduanya dalam konteks Unified Namespace (UNS) dan kebutuhan Industri 4.0 (reliability, scalability, interoperability, security, hingga maintenance) melalui paper analisis performa OPC UA dan MQTT untuk solusi data-centric/UNS. Tema ini layak diangkat karena banyak engineer dan developer masih memandang OT vs IT sebagai tembok—padahal yang dibutuhkan adalah bridge yang disiplin: aman, terukur, dan mudah dipelihara.

“Kalau data mesin itu bahan baku, maka arsitektur adalah pabriknya: menentukan alirannya, kualitasnya, dan siapa yang boleh menyentuhnya.”

1. Masalah Nyata di Lantai Produksi

Kalau kamu pernah diminta “tarik data mesin ke dashboard minggu ini”, kamu pasti tahu jebakannya: protokol legacy, jaringan segmented, dan kekhawatiran downtime. Sebelum ngomong tool, kita butuh bahasa yang sama tentang apa yang ingin dicapai dan batasan yang tidak boleh dilanggar.

Apa yang biasanya terjadi (dan kenapa sering gagal)

Data terfragmentasi: tiap mesin/vendor punya cara sendiri.
Akses OT ad-hoc: “buka port dulu, nanti ditutup” (spoiler: sering lupa).
Skala tidak kepikiran: PoC jalan, produksi megap-megap.
Security dipikir belakangan: padahal OT punya konsekuensi safety.

Target yang realistis

Telemetri mesin real-time (bukan perfect real-time, tapi cukup untuk OEE, alerting, traceability).
Integrasi bertahap: mulai dari 1 line → 1 plant.
Security-by-design: least privilege, segmentation, dan audit.

2. MQTT vs OPC UA: Bukan Pilih Salah Satu

Di debat “MQTT atau OPC UA”, jawaban paling berguna seringnya: keduanya, dengan peran yang jelas. MQTT unggul untuk lightweight pub/sub dan distribusi event, sementara OPC UA unggul untuk data model yang kaya, konteks semantik, dan kontrol akses yang matang. Di sinilah arsitektur iiot mqtt opcua paling masuk akal.

Tabel cepat: kapan pakai apa

Kebutuhan	MQTT	OPC UA
Messaging pub/sub skala besar	✅ kuat	⚠️ bisa, tapi lebih “berat”
Data model semantik (tag, tipe, struktur)	⚠️ butuh konvensi/topik	✅ native (nodes, types)
Integrasi cepat ke aplikasi/cloud	✅ sangat umum	✅ umum di industri
Telemetri perangkat low-power	✅ ideal	❌ relatif berat
Akses baca/tulis terkontrol (policy)	⚠️ bergantung broker/auth	✅ built-in security model

Pola favorit: OPC UA di edge, MQTT di backbone

OPC UA: dekat mesin/PLC (baca tag, struktur data, context).
MQTT: distribusi event ke sistem lain (dashboard, historian, analytics).

Internal link Dev.to yang relevan untuk pendalaman:

OPC UA over MQTT: The Future of IT and OT Convergence

The Easiest Guide to Getting Started with MQTT

3. Blueprint Arsitektur: Dari Mesin → Edge → Cloud

Kita bikin arsitektur yang boring but reliable. Prinsipnya: kecilkan blast radius, bikin data mudah dipakai, dan jaga jalur komunikasi tetap terkendali. Inilah kerangka arsitektur iiot mqtt opcua yang aman untuk jalan panjang.

Komponen inti

Data source: PLC, sensor, CNC, robot controller, power meter.
Edge gateway: industrial PC/IPC (kolektor + buffer + transform).
OPC UA server/client: akses data tag dengan struktur.
MQTT broker: event backbone (on-prem, cloud, atau hybrid).
Consumers: SCADA/monitoring, MES, ERP, data lake, AI/ML.

Diagram mental (tanpa gambar dulu)

Northbound ke IT: MQTT/TLS (publish telemetry)
Southbound ke OT: OPC UA (baca data terstruktur)
Sidecar: observability (metrics/logs), dan policy enforcement

UNS sebagai “bahasa bersama”

Kalau organisasi kamu ingin data rapi lintas lini pabrik, pertimbangkan konsep Unified Namespace (UNS):

Struktur topik konsisten (site/area/line/cell/machine/metric)
Konvensi unit, timestamp, quality
Versi skema data (biar tidak “breaking change” diam-diam)

4. Keamanan OT: Desain Dulu, Baru Sambung

Satu hal yang sering dilupakan: menghubungkan OT ke cloud bukan masalah teknis semata, tapi desain risiko. Jadikan keamanan sebagai bagian dari arsitektur, bukan checklist akhir. Ini juga konsisten dengan prinsip-prinsip konektivitas OT yang menekankan tata kelola, segmentasi, dan kontrol akses.

Kontrol yang wajib dipertimbangkan

Network segmentation: OT zone ↔ DMZ ↔ IT zone
Zero Trust “versi pabrik”: identitas, device posture, dan context-aware access
TLS end-to-end: enkripsi + certificate lifecycle (rotasi, revokasi)
Least privilege: user/service account spesifik, bukan “admin semua”
Auditability: siapa publish apa, kapan, dari mana

Anti-pattern yang perlu dihindari

Membuka akses remote langsung ke PLC tanpa jump host
Broker MQTT tanpa ACL/topik policy
Credential statis ditempel di device image

5. Langkah Implementasi Praktis (How-To)

Bab ini sengaja dibuat bisa di-copy-paste jadi rencana eksekusi. Fokus: jalan dulu, aman dulu, baru canggih.

Checklist tahap 0 — sebelum menyentuh jaringan

Tentukan use case: OEE, downtime reason, energi, traceability, predictive maintenance.
Definisikan data minimal: 10–30 tag paling berdampak.
Tentukan SLA data: 1 detik? 5 detik? event-based?

Tahap 1 — Edge collector (OPC UA)

Inventaris tag PLC
Buat mapping node/tag → struktur data yang konsisten
Aktifkan buffering (store-and-forward) untuk kasus jaringan putus

Tahap 2 — Publish ke MQTT (dengan aturan topik)

Contoh konvensi topik UNS sederhana:

karawang/plant-a/line-1/cell-2/machine-press01/telemetry
karawang/plant-a/line-1/cell-2/machine-press01/events

Payload: gunakan JSON yang ringan, dengan field yang stabil.

Tahap 3 — Konsumen data (dashboard, historian, analytics)

Dashboard: alert, OEE, trend
Historian/data lake: analitik jangka panjang
AI/ML: hanya setelah data clean dan stable

Tahap 4 — Observability & hardening

Metrics broker (latency, dropped messages)
Log correlation (trace-id)
Certificate rotation
Pengetesan pemulihan (disaster recovery) minimal 2x setahun

6. Studi Kasus Ringkas: “Real-Time” yang Benar-benar Dipakai

Supaya tidak berhenti di istilah, berikut pola yang sering berhasil di manufaktur:

Problem: downtime tidak tercatat akurat, data “telat” di laporan.
Solusi: event downtime dari PLC (OPC UA) → publish MQTT ke dashboard + historian.
Hasil yang dicari: alert < 10 detik, analisis harian tanpa manual input.

Poin penting: real-time bukan untuk gaya—tapi untuk mengurangi waktu reaksi dan membuktikan root cause.

FAQ

Apakah MQTT aman untuk data industri?

Aman kalau kamu menerapkan TLS, authentication yang benar, dan ACL/topik policy. Tanpa itu, MQTT hanya “pipa” yang mudah disalahgunakan.

Kenapa tidak pakai OPC UA saja end-to-end?

Bisa, tapi banyak organisasi memilih MQTT untuk distribusi event skala besar dan integrasi cepat dengan banyak konsumen. Kombinasi keduanya sering lebih fleksibel.

Bagaimana menangani koneksi internet yang tidak stabil?

Gunakan edge buffering (store-and-forward), QoS MQTT yang sesuai, dan desain retry/backoff agar sistem tidak storming.

Apakah konsep UNS harus dari awal?

Tidak harus. Kamu bisa mulai dengan konvensi topik sederhana, lalu evolusi ke UNS saat cakupan makin luas.

Bisa implement hybrid (on-prem + cloud)?

Bisa, dan sering ideal. Data sensitif tetap on-prem, sementara agregasi/analytics tertentu naik ke cloud.

Siap Membuat Data Mesin “Naik Kelas”?

Sebagai penutup, ada kutipan yang selalu relevan saat OT mulai terhubung ke cloud:

“Security is a process, not a product.” — Bruce Schneier

Artinya: keamanan bukan barang sekali beli, melainkan proses berkelanjutan—mulai dari desain arsitektur, operasi harian, sampai perbaikan saat insiden. Schneier adalah kriptografer dan pakar keamanan komputer yang dikenal luas karena menekankan keamanan sebagai disiplin rekayasa, bukan sekadar tool. Dalam konteks arsitektur iiot mqtt opcua, pesan ini mengingatkan kita: konektivitas shopfloor ke cloud harus dibangun dengan tata kelola, pengujian, dan pemeliharaan yang konsisten.

Jika tim kamu sedang merancang integrasi engineering–machining–automation dari sisi manufaktur (khususnya di area Karawang dan sekitarnya), kamu bisa melihat profil layanan kami di PT. Satya Abadi Raya untuk konteks implementasi di dunia nyata—mulai dari rekayasa, fabrikasi, hingga otomasi industri.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Membangun Arsitektur IIoT (MQTT + OPC UA) untuk Data Mesin Real-Time dan Aman",
  "description": "Panduan praktis membangun arsitektur IIoT yang menggabungkan OPC UA di edge dan MQTT sebagai backbone messaging untuk mengalirkan data mesin ke cloud dengan kontrol keamanan yang tepat.",
  "totalTime": "PT6H",
  "supply": [
    {"@type": "HowToSupply", "name": "Industrial PC/Edge gateway"},
    {"@type": "HowToSupply", "name": "Akses OPC UA ke PLC/mesin"},
    {"@type": "HowToSupply", "name": "MQTT broker (on-prem atau cloud)"},
    {"@type": "HowToSupply", "name": "Sertifikat TLS dan kebijakan akses"}
  ],
  "tool": [
    {"@type": "HowToTool", "name": "OPC UA client/server"},
    {"@type": "HowToTool", "name": "MQTT client"},
    {"@type": "HowToTool", "name": "Monitoring & logging stack"}
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "Definisikan use case dan SLA data",
      "text": "Pilih 1 use case (mis. OEE atau downtime alert), tentukan daftar tag prioritas, dan definisikan kebutuhan latency (mis. 1–10 detik)."
    },
    {
      "@type": "HowToStep",
      "name": "Bangun edge collector dengan OPC UA",
      "text": "Inventaris tag PLC/mesin, buat mapping node/tag menjadi struktur data konsisten, dan aktifkan buffering untuk kondisi jaringan tidak stabil."
    },
    {
      "@type": "HowToStep",
      "name": "Tetapkan konvensi topik UNS di MQTT",
      "text": "Susun hirarki topik (site/line/cell/machine/metric) dan standar payload (timestamp, unit, quality) agar data mudah dipakai lintas sistem."
    },
    {
      "@type": "HowToStep",
      "name": "Aktifkan keamanan konektivitas",
      "text": "Terapkan segmentasi OT–DMZ–IT, TLS end-to-end, identitas perangkat, ACL/topik policy, dan audit log untuk setiap publish/subscribe."
    },
    {
      "@type": "HowToStep",
      "name": "Integrasikan konsumen data dan observability",
      "text": "Hubungkan dashboard/historian/analytics, pasang monitoring broker (latency/dropped), korelasi log, dan rencanakan rotasi sertifikat."
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "PT. Satya Abadi Raya",
    "url": "https://satya-abadi.co.id/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://satya-abadi.co.id/"
  }
}

DEV Community