Bagaimana Data Mesin Mencapai Microsoft Fabric - Dari OPC UA hingga Analitik Real-Time

Mendapatkan alarm mesin, nilai sensor, penghitung produksi, dan event kerusakan ke cloud kini semakin mudah. OPC UA menyediakan sinyal mesin, lapisan edge mengumpulkannya, MQTT dapat mendistribusikannya secara lokal, dan Microsoft Fabric dapat menyerap serta menganalisis aliran data yang dihasilkan. Namun bagian yang sulit dimulai setelah data tiba: bagaimana cara mengubah telemetri mentah menjadi konteks produksi yang cukup untuk mendukung keputusan yang nyata?

Episode ini mengikuti satu sinyal mesin dari lantai pabrik hingga melalui tumpukan data industri Microsoft. Dimulai dengan OPC UA, bergerak melalui edge dan MQTT, melintas secara aman ke Azure dan Microsoft Fabric, lalu melihat bagaimana Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, data pemeliharaan, dan konteks produksi saling terhubung. Tujuannya bukan sekadar menunjukkan satu pipeline telemetri lagi. Tujuannya adalah menjelaskan apa yang harus terjadi sebelum data mesin menjadi berguna bagi produksi, pemeliharaan, kualitas, dan perencanaan.

DARI HENTINYA MESIN HINGGA KONSEKUENSI PRODUKSI
Penghentian mesin terlihat sederhana pada tingkat controller. Status berubah dari berjalan menjadi mengalami gangguan, sebuah kode kesalahan muncul, penghitung part berhenti, dan mungkin nilai lain ikut berubah di waktu yang sama. Informasi ini berguna, tetapi produksi biasanya mengajukan pertanyaan yang berbeda: work order mana yang terdampak, berapa jumlah yang tersisa, dapatkah mesin lain mengambil alih, dan apakah penundaan ini mengancam pengiriman?

Mesin memahami kondisinya sendiri, tetapi tidak secara otomatis memahami konsekuensi bisnisnya. MES mungkin mengetahui operasi dan work order. ERP mungkin mengetahui tanggal jatuh tempo dan permintaan. Pemeliharaan dapat memahami riwayat peralatan. Kualitas dapat menentukan apakah output masih dapat digunakan. Itulah sebabnya pipeline telemetri yang cepat hanyalah awal dari arsitektur.

OPC UA — TEMPAT SINYAL MASUK KE JALUR DATA
OPC UA menyediakan antarmuka industri terstandar untuk mengakses informasi dari peralatan tanpa mengharuskan setiap aplikasi cloud memahami protokol controller yang bersifat proprietary. Sebuah server dapat mengekspos variabel, status mesin, alarm, event, metode, timestamp, informasi kualitas, dan terkadang model peralatan yang terstruktur.

Struktur ini penting karena event industri yang berguna seharusnya membawa lebih dari sekadar nilai numerik. Source timestamp, server timestamp, status kualitas, satuan, identitas sumber, dan informasi node OPC UA asli dapat menjadi penting nantinya ketika seseorang bertanya dari mana sebuah angka berasal atau mengapa sebuah perhitungan produksi tampak janggal.

Episode ini juga menekankan bahwa nama tag bukanlah model data. Sebuah field bernama "temperature" atau "machine state" tetap membutuhkan konteks seperti aset, satuan teknik, rentang yang diizinkan, definisi status, dan situasi produksi tempat sinyal tersebut diamati.

MENJAGA BATAS OT TETAP TERKENDALI
Konektivitas mesin tidak boleh mengubah jaringan produksi menjadi perpanjangan dari lingkungan korporat atau cloud. Jaringan industri membutuhkan batas yang terkendali, biasanya mencakup segmentasi dan DMZ industri, sehingga sistem edge yang disetujui dapat berkomunikasi dengan peralatan tanpa memberi aplikasi perusahaan akses langsung ke controller.

Pola yang direkomendasikan umumnya berorientasi outbound. Lapisan edge terhubung ke endpoint OPC UA yang disetujui lalu mengirimkan informasi terpilih menuju layanan cloud melalui tujuan, port, protokol, dan identitas yang terkontrol. Platform analitik seharusnya menerima data tanpa mewarisi hak luas untuk menelusuri atau mengubah sistem produksi.

Sertifikat, aturan firewall, hubungan kepercayaan, penanganan masa berlaku, dan kepemilikan juga perlu diperlakukan sebagai proses operasional, bukan pekerjaan konfigurasi satu kali.

EDGE SEHARUSNYA MENINGKATKAN DATA — BUKAN MENCIPTAKAN MAKNA BISNIS
Lapisan edge berada di antara lingkungan mesin dan platform data yang lebih luas. Tanggung jawab pertamanya adalah koneksi, tetapi ia juga dapat melakukan filter, normalisasi, buffering, pengayaan, dan routing informasi sebelum meninggalkan pabrik.

Tanggung jawab edge yang berguna meliputi:
• Memilih hanya sinyal yang diperlukan untuk kasus penggunaan yang ditetapkan
• Memfilter data frekuensi tinggi yang tidak perlu
• Menerapkan konversi satuan yang telah disepakati
• Mempertahankan source timestamp dan indikator kualitas
• Menambahkan identifier situs, lini, dan aset yang stabil
• Melakukan buffering saat terjadi gangguan cloud
• Menangani perilaku retry dan back-pressure
• Mengekspos kesehatan connector dan antrean
• Melakukan perhitungan lokal terpilih atau inferensi AI ketika latensi atau operasi terputus memerlukannya

Batas yang penting adalah edge sebaiknya hanya menambahkan fakta yang diketahuinya dengan keyakinan. Ia tidak boleh menebak production order mana yang aktif berdasarkan informasi usang atau diam-diam membuat konteks bisnis yang seharusnya menjadi milik sistem MES, ERP, perencanaan, atau kualitas.

AZURE IOT EDGE VS AZURE IOT OPERATIONS
Episode ini membandingkan dua pendekatan Microsoft untuk menjalankan beban kerja edge industri.
Azure IoT Edge cocok ketika kebutuhannya berfokus pada gateway atau perangkat individual. Modul yang dikontainerisasi dapat mengumpulkan data, menerapkan logika lokal, melakukan buffering informasi, dan mengirimkannya ke hulu melalui Azure IoT Hub. Ini dapat menjadi pilihan praktis untuk sel yang terdefinisi atau beban kerja yang lebih kecil ketika organisasi menginginkan jejak operasional yang lebih ringan.

Azure IoT Operations lebih diposisikan sebagai lingkungan data industri tingkat situs. Ia berjalan di lingkungan Kubernetes yang diaktifkan Azure Arc dan mencakup kemampuan seputar konektivitas OPC UA, MQTT, alur data, serta manajemen aset atau perangkat. Hal ini bisa lebih masuk akal ketika sebuah situs memiliki beberapa lini, berbagai vendor mesin, konsumen lokal, dan kebutuhan untuk mereplikasi pola edge yang terkelola di berbagai pabrik.

Keputusan sebaiknya tidak didasarkan pada platform mana yang memiliki daftar fitur terpanjang. Keputusan sebaiknya didasarkan pada model operasi yang siap didukung organisasi. Azure IoT Operations menyediakan kemampuan tingkat situs yang lebih luas, tetapi juga memperkenalkan tanggung jawab terkait Kubernetes, Arc, operasi cluster, pemantauan, penyimpanan, patching, dan pemulihan.

MQTT SEBAGAI TULANG PUNGGUNG EVENT PABRIK
Ketika beberapa konsumen membutuhkan event mesin yang sama, MQTT dapat secara drastis menyederhanakan arsitektur. Machine connector mempublikasikan sekali ke broker, dan aplikasi pemeliharaan, historian lokal, alur data cloud, atau konsumen lain yang disetujui berlangganan secara independen.

Hal ini menghilangkan banyak ketergantungan point-to-point. Aplikasi baru dapat berlangganan ke topik yang disetujui tanpa membuat tautan langsung lain ke PLC atau server OPC UA.

Desain topik tetap penting. Hierarki dapat merepresentasikan situs, area, lini, sel, dan aset, tetapi topik sebaiknya tidak menjadi seluruh model data. Fakta penting seperti identitas event, source timestamp, ID aset, kualitas, versi kontrak, dan tipe event sebaiknya tetap berada di dalam payload pesan sehingga event tetap dapat dipahami meskipun disimpan, diputar ulang, atau dirutekan ke tempat lain.

UNIFIED NAMESPACE ADALAH KONTRAK — BUKAN SEKADAR POHON TOPIK
Pola Unified Namespace dapat menyediakan kontrak operasional bersama di seluruh sistem industri. Bagian yang berguna bukan sekadar memiliki satu hierarki MQTT yang besar. Nilainya berasal dari kesepakatan tentang cara aset diidentifikasi, bagaimana event dibentuk, siapa pemilik data, bagaimana skema berubah, dan sistem mana yang berwenang untuk fakta yang berbeda.

Unified Namespace yang baik dapat menyediakan cara yang stabil untuk mengidentifikasi aset dan mempublikasikan event operasional yang terkelola, sambil membiarkan sistem sumber tetap memiliki kepemilikan atas catatan mereka sendiri.

Kontrak tersebut sebaiknya mendefinisikan hal-hal seperti:
• Identitas aset
• Tipe event
• Bentuk pesan
• Aturan timestamp
• Informasi kualitas
• Kepemilikan
• Keamanan
• Versioning
• Manajemen perubahan

MQTT dapat mengangkut kontrak tersebut, tetapi MQTT tidak menciptakan kontrak itu sendiri.

DARI NOTIFIKASI OPC UA KE EVENT MQTT
Mengubah notifikasi OPC UA menjadi event MQTT lebih dari sekadar translasi protokol. Connector perlu...