IoT Hub Message Routing vs Event Grid — Mengapa Telemetri dan Event Bukan Masalah yang Sama

Mesin mengirimkan pembacaan suhu, data getaran, jumlah siklus, konsumsi daya, dan status operasi setiap beberapa detik. Lalu gateway tiba-tiba terputus. Apakah semua pesan tersebut hanya “event”? Secara teknis, bisa saja disebut demikian. Secara arsitektur, pendekatan itu dapat menimbulkan masalah serius. Azure IoT Hub Message Routing dan Azure Event Grid memecahkan masalah yang berbeda. Jalur yang satu dirancang untuk mempertahankan dan mendistribusikan data operasional. Jalur yang lain dirancang untuk memberi tahu sistem bahwa sesuatu telah berubah dan mungkin memerlukan respons. Menganggap keduanya dapat saling menggantikan bisa membuat alur kerja mahal yang memproses data sensor rutin, atau sinyal penting terkubur di dalam pipeline telemetri yang tidak ada yang sedang memantaunya. Dalam episode ini dari M365 FM, kami mengikuti sebuah mesin manufaktur melalui arsitektur Azure IoT yang nyata dan menjelaskan di mana IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions, dan Logic Apps sebenarnya ditempatkan.

APA YANG AKAN ANDA PELAJARI
Dalam episode ini, kami membahas:

• Mengapa telemetri mesin dan event bisnis atau siklus hidup yang bersifat diskret memerlukan pola arsitektur yang berbeda
• Cara kerja Azure IoT Hub Message Routing sebagai bagian dari data plane telemetri
• Di mana Azure Event Grid berperan dalam arsitektur berbasis event dan reaktif
• Mengapa urutan pesan penting untuk telemetri manufaktur
• Mengapa Event Grid sebaiknya tidak menjadi bus telemetri volume tinggi utama Anda
• Mengapa routing IoT Hub tidak perlu dipaksakan ke setiap alur kerja notifikasi
• Bagaimana IoT Hub dan Event Grid dapat bekerja sama dalam arsitektur yang sama
• Bagaimana Event Hubs dapat mendukung konsumen pemrosesan aliran yang independen
• Mengapa data telemetri mentah sebaiknya sering disimpan untuk keperluan keterlacakan dan investigasi di kemudian hari
• Bagaimana Microsoft Fabric dan Power BI dapat mengonsumsi data operasional yang telah disiapkan
• Mengapa MES, ERP, dan model aset memberikan konteks yang tidak dapat diberikan oleh data perangkat saja
• Cara menafsirkan event pemutusan perangkat tanpa secara otomatis berasumsi bahwa produksi berhenti
• Bagaimana pengiriman ganda, percobaan ulang, timestamp, dan idempotensi memengaruhi arsitektur industri yang andal
• Cara merancang alur kerja pemantauan kondisi, pemeliharaan prediktif, keterlacakan kualitas, dan gangguan produksi
• Cara memutuskan apakah sebuah pesan termasuk pada data plane, jalur respons, atau keduanya

TELEMETRI ADALAH CATATAN SEPANJANG WAKTU
Telemetri tidak bernilai karena satu pembacaan suhu telah diterima. Nilainya muncul ketika ribuan pembacaan bersama-sama menggambarkan apa yang terjadi. Sebuah mesin produksi dapat terus-menerus melaporkan:

• Pengukuran suhu dan getaran
• Arus motor dan konsumsi energi
• Jumlah siklus dan penghitung produksi
• Status berjalan, idle, berhenti, atau mengalami kesalahan
• Timestamp sumber dan informasi urutan
• Informasi diagnostik dan kesehatan peralatan

Satu nilai suhu mungkin berarti sangat sedikit. Urutan di sekitar pembacaan itu yang menceritakan kisahnya. Apakah mesin sedang memanas? Apakah mesin sudah berproduksi? Apakah getaran meningkat pada saat yang sama? Apakah waktu siklus mulai bertambah? Apakah mesin berhenti tak lama kemudian? Oleh karena itu, telemetri memerlukan jalur yang dirancang berdasarkan urutan, retensi, pemutaran ulang, konsumen independen, dan keterlacakan.

EVENT ADA UNTUK MEMULAI RESPONS
Event memiliki tujuan lain. Event menyatakan: Sesuatu telah berubah. Suatu sistem atau orang mungkin perlu bereaksi. Contohnya meliputi:

• Perangkat baru telah didaftarkan
• Gateway terputus dari IoT Hub
• Perangkat terhubung kembali
• Perangkat dihapus
• Proses pemantauan mendeteksi kondisi yang memerlukan investigasi
• Inspeksi selesai dan alur kerja lain dapat dimulai

Penerima biasanya tidak memerlukan berjam-jam telemetri sebelum memulai langkah pertama. Yang dibutuhkan adalah informasi yang cukup untuk mengidentifikasi apa yang terjadi dan menentukan respons yang tepat. Respons tersebut dapat meliputi:

• Memulai Azure Function
• Memicu Logic App
• Membuka investigasi dukungan
• Memperbarui catatan aset
• Memeriksa status perangkat saat ini
• Memanggil aplikasi eksternal melalui webhook
• Memberi tahu tim yang bertanggung jawab atas sistem yang terdampak

Event memulai investigasi. Event tidak selalu berisi setiap fakta yang diperlukan untuk membuat keputusan operasional akhir.

MENGAPA “SEMUANYA ADALAH EVENT” GAGAL
Mengirim setiap pengukuran sensor ke alur kerja yang dipicu event mungkin terlihat menarik selama proof of concept. Lalu skala produksi tiba. Setiap pembacaan memicu Function lain. Logic App lain mengevaluasi sesuatu. Integrasi lain menerima pesan lain. Pemeliharaan membuat langganannya sendiri. Kualitas membuat yang lain. Manajemen energi membuat yang lain lagi. Tak lama kemudian, setiap tim memiliki penyaringan, penanganan status, penanganan percobaan ulang, dan logika penyimpanan yang sedikit berbeda. Pengukuran suhu bukan otomatis sebuah insiden. Pengukuran itu mungkin berkontribusi pada insiden nanti, tetapi pengukuran berkelanjutan sebaiknya tetap tersedia sebagai bukti. Ketika telemetri rutin mulai menghasilkan notifikasi yang terus-menerus, pengguna juga bisa mulai mengabaikan peringatan karena sistem telah membiasakan mereka dengan kebisingan, bukan informasi yang dapat ditindaklanjuti.

APA YANG SEBENARNYA DILAKUKAN AZURE IOT HUB
Azure IoT Hub menyediakan batas cloud yang menghadap perangkat. Ia mendukung area seperti:

• Identitas perangkat yang aman
• Pesan dari perangkat ke cloud
• Komunikasi dari cloud ke perangkat
• Manajemen perangkat
• Device twin
• Akses terkontrol antara peralatan yang terhubung dan layanan Azure

IoT Hub mengetahui bahwa perangkat yang terautentikasi mengirim sebuah pesan. Ia tidak secara otomatis memahami apa arti pesan tersebut bagi produksi. Sebuah gateway mungkin melaporkan: state = running Tetapi “running” bisa berarti:

• Memproduksi part yang disetujui
• Dry cycling
• Menjalankan setup
• Melakukan rework
• Bergerak tanpa material

Konteks tersebut biasanya berasal dari sistem tambahan seperti MES, ERP, model aset, atau aplikasi produksi.

Jadilah pendukung podcast ini: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.