توجيه رسائل IoT Hub مقابل Event Grid — لماذا لا تمثل القياسات عن بُعد والأحداث المشكلة نفسها

يرسل جهاز صناعي قراءات الحرارة وبيانات الاهتزاز وعدّادات الدورات واستهلاك الطاقة وحالات التشغيل كل بضع ثوانٍ. ثم ينقطع الاتصال بالبوابة فجأة. هل كل هذه الرسائل مجرد "أحداث"؟ من الناحية التقنية يمكن وصفها بذلك. أما من ناحية الهندسة المعمارية، فقد يؤدي ذلك إلى مشكلات خطيرة. فـAzure IoT Hub Message Routing وAzure Event Grid يحلان مشكلات مختلفة. المسار الأول مصمم للحفاظ على بيانات التشغيل وتوزيعها، بينما المسار الثاني مصمم لإشعار الأنظمة بأن شيئًا ما قد تغيّر وقد يتطلب استجابة. ومعاملتهما كأنهما متبادلان قد تنتج عنها سير عمل مكلف يعالج بيانات حساسات روتينية، أو إشارات مهمة مدفونة داخل خط أنابيب للقياسات عن بُعد لا يراقبه أحد بنشاط. في هذه الحلقة من M365 FM، نتتبع آلة تصنيع عبر بنية Azure IoT حقيقية، ونشرح أين يقع فعليًا كل من IoT Hub وEvent Grid وEvent Hubs وMicrosoft Fabric وPower BI وMES وERP وFunctions وLogic Apps.

ما ستتعلمه

في هذه الحلقة نستكشف:

• لماذا تتطلب القياسات عن بُعد للآلات وأحداث الأعمال أو دورة الحياة المنفصلة أنماط هندسة معمارية مختلفة
• كيف يعمل Azure IoT Hub Message Routing كجزء من مستوى بيانات القياسات عن بُعد
• أين يقع Azure Event Grid في الأنظمة المعتمدة على الأحداث والأنظمة التفاعلية
• لماذا يهم ترتيب الرسائل بالنسبة لقياسات التصنيع عن بُعد
• لماذا لا ينبغي أن يصبح Event Grid ناقل القياسات الأساسي عالي الحجم
• لماذا لا ينبغي فرض توجيه IoT Hub على كل سير عمل للإشعارات
• كيف يمكن لـIoT Hub وEvent Grid العمل معًا ضمن البنية نفسها
• كيف يمكن لـEvent Hubs دعم مستهلكين مستقلين لمعالجة التدفقات
• لماذا ينبغي غالبًا الاحتفاظ بالقياسات الخام لأغراض التتبع والتحقيق اللاحق
• كيف يمكن لـMicrosoft Fabric وPower BI استهلاك بيانات التشغيل المُعدّة
• لماذا توفر أنظمة MES وERP ونماذج الأصول سياقًا لا يمكن لبيانات الأجهزة وحدها توفيره
• كيف ينبغي تفسير أحداث انقطاع الجهاز دون افتراض تلقائي بأن الإنتاج قد توقف
• كيف تؤثر إعادة الإرسال المكرر والمحاولات والطوابع الزمنية وخاصية idempotency على موثوقية البنى الصناعية
• كيفية تصميم سير عمل لمراقبة الحالة والصيانة التنبؤية وتتبع الجودة وتعطل الإنتاج
• كيفية تحديد ما إذا كانت الرسالة تنتمي إلى مستوى البيانات أو مسار الاستجابة أو إلى كليهما

القياسات عن بُعد سجل عبر الزمن

القياس عن بُعد ليس ذا قيمة لأن قراءة حرارة واحدة وصلت. بل تكتسب قيمته عندما تصف آلاف القراءات مجتمعةً ما حدث. قد تُبلغ آلة إنتاج باستمرار عن:

• قياسات الحرارة والاهتزاز
• تيار المحرك واستهلاك الطاقة
• عدّادات الدورات والعدّادات الإنتاجية
• حالات التشغيل أو الخمول أو التوقف أو العطل
• الطوابع الزمنية للمصدر ومعلومات التسلسل
• معلومات التشخيص وصحة المعدات

قد تعني قراءة حرارة واحدة القليل، لكن التسلسل المحيط بها هو ما يروي القصة. هل كانت الآلة في طور الإحماء؟ هل كانت تنتج بالفعل؟ هل كان الاهتزاز يزداد في الوقت نفسه؟ هل بدأ زمن الدورة بالارتفاع؟ هل توقفت الآلة بعد وقت قصير؟ لذلك يحتاج القياس عن بُعد إلى مسار مصمم حول التسلسل والاحتفاظ بالبيانات وإعادة تشغيلها والمستهلكين المستقلين والتتبع.

الأحداث موجودة لبدء الاستجابة

للحدث غرض مختلف. فالحدث يقول: شيء ما تغيّر. وقد يحتاج نظام أو شخص ما إلى التفاعل. من الأمثلة:

• تسجيل جهاز جديد
• انفصال بوابة عن IoT Hub
• إعادة اتصال جهاز
• حذف جهاز
• عملية مراقبة اكتشفت حالة تستوجب التحقيق
• اكتمال فحص يمكن أن يبدأ عنده سير عمل آخر

لا يحتاج المستلم عادةً إلى ساعات من القياسات قبل بدء الخطوة الأولى، بل يحتاج إلى معلومات كافية لتحديد ما حدث وتحديد الاستجابة المناسبة. وقد تتضمن هذه الاستجابة:

• تشغيل Azure Function
• تفعيل Logic App
• فتح تحقيق دعم فني
• تحديث سجل الأصل
• التحقق من حالة الجهاز الحالية
• استدعاء تطبيق خارجي عبر webhook
• إخطار الفريق المسؤول عن النظام المتأثر

الحدث يبدأ التحقيق، ولا يحتوي بالضرورة على كل الحقائق اللازمة لاتخاذ القرار التشغيلي النهائي.

لماذا يتعطل مبدأ "كل شيء حدث"

قد يبدو إرسال كل قراءة حساس إلى سير عمل يُفعَّل بالأحداث جذابًا خلال مرحلة الإثبات المفاهيمي. لكن عند الوصول إلى نطاق الإنتاج، تتولد كل قراءة دالة أخرى، ويقيّم كل منطق آخر شيئًا ما، وتستقبل كل تكاملية رسالة أخرى. ثم تنشئ الصيانة اشتراكها الخاص، وتنشئ الجودة اشتراكها، وكذلك إدارة الطاقة. وسرعان ما تمتلك كل فرق منطق تصفية وإدارة حالة ومعالجة إعادة محاولة وتخزين مختلفًا قليلًا. قراءة الحرارة ليست حادثًا تلقائيًا، فقد تسهم في حادث لاحقًا، لكن القياسات المستمرة ينبغي أن تبقى متاحة كدليل. وعندما تولّد القياسات الروتينية إشعارات متواصلة، يبدأ المستخدمون بتجاهل التنبيهات لأن النظام درّبهم على توقع الضوضاء لا المعلومات القابلة للتنفيذ.

ما الذي يفعله Azure IoT Hub فعليًا

يوفر Azure IoT Hub الحد السحابي الذي يواجه الأجهزة. ويدعم مجالات مثل:

• هويات أجهزة آمنة
• مراسلة من الجهاز إلى السحابة
• الاتصال من السحابة إلى الجهاز
• إدارة الأجهزة
• توائم الأجهزة (device twins)
• وصول مضبوط بين المعدات المتصلة وخدمات Azure

يعرف IoT Hub أن جهازًا موثَّقًا أرسل رسالة، لكنه لا يفهم تلقائيًا ما تعنيه تلك الرسالة للإنتاج. فقد تُبلغ البوابة عن: state = running لكن "running" قد تعني:

• إنتاج قطع معتمدة
• تشغيل جاف (dry cycling)
• تشغيل الإعداد
• تنفيذ إعادة العمل
• حركة بدون مادة

غالبًا ما يأتي هذا السياق من أنظمة إضافية مثل MES أو ERP أو نموذج الأصول أو تطبيق الإنتاج.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.