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

يمكن وصف قراءة درجة حرارة، وعينة اهتزاز، ودورة آلة، وفصل جهاز جميعها بأنها أحداث، لكنها لا تمثل المشكلة المعمارية نفسها. ففي بيئات إنترنت الأشياء الصناعي والتصنيع، يؤدي الخلط بين القياس المستمر (Telemetry) والأحداث المنفصلة إلى سير عمل مزدحم بالضوضاء، وسجلات إنتاج غير مكتملة، ومعالجة غير ضرورية، وأنظمة تتفاعل دون سياق كافٍ.

في هذه الحلقة، نشرح الفرق المعماري بين Azure IoT Hub Message Routing وAzure Event Grid من خلال تتبع سيناريو تصنيعي واقعي. يرسل خط مكبس قياسات مستمرة لدرجة الحرارة والاهتزاز وعدد الدورات واستهلاك الطاقة وحالة الآلة عبر بوابة صناعية. تُنشئ هذه القياسات سجلاً تشغيلياً قد يحتاج المهندسون وفرق البيانات وفرق الصيانة والأنظمة الإنتاجية إلى تحليله لاحقاً. أما فصل الجهاز فهو مختلف، لأنه يمثل تغييراً قد يتطلب تفاعلاً من نظام آخر أو شخص آخر.

القياس المستمر سجل، وليس تنبيهاً

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

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

قد تدعم هذه السجلات لاحقاً مراقبة الحالة، وتحقيقات الجودة، وتحليل الطاقة، وحساب OEE، وتحليلات Microsoft Fabric، وتقارير Power BI، وتحسين الإنتاج. لذلك يحتاج القياس المستمر إلى الاحتفاظ بالبيانات، وإعادة التشغيل، ومعالجة التكرار، ومستهلكين مستقلين، وطريقة موثوقة لإعادة بناء الخط الزمني للإنتاج.

IoT Hub Message Routing كمستوى بيانات للقياس المستمر

توفر Azure IoT Hub الحد المُتحكَّم فيه بين الأجهزة والسحابة. تصادق الأجهزة والبوابات بهوياتها الخاصة، وترسل رسائل من الجهاز إلى السحابة، وتحافظ على حالة إدارة الأجهزة، ويمكنها المشاركة في اتصال مُتحكَّم فيه من السحابة إلى الجهاز.

عندما تصل رسالة القياس إلى IoT Hub، يحدد Message Routing المكان الذي يجب أن تذهب إليه هذه البيانات. يمكن للتوجيه فحص خصائص الرسالة، والخصائص النظامية، وأجزاء من متن الرسالة، ومعلومات الجهاز Device Twin. وهذا يتيح فصل فئات الرسائل، مثل القياسات الإنتاجية، أو بيانات الطاقة، أو التشخيصات، قبل وصولها إلى المستهلكين اللاحقين.
قد تبدو بنية شائعة كالتالي: البوابة الصناعية ← Azure IoT Hub ← Message Routing ← Event Hubs أو Storage ← المعالجة ← Microsoft Fabric.

قد يُجري أحد المستهلكين تحليلاً شبه فوري، بينما يحتفظ آخر بأرشيف خام. ويُعد مستهلك ثالث بيانات تشغيلية منسقة لـ Microsoft Fabric. ويمكن لكل مستهلك العمل بشكل مستقل دون تحويل كل قراءة قياس إلى استدعاء لسير عمل.

لماذا يهم الترتيب

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

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

ينبغي أن تأخذ بنية القياس المتينة في الحسبان:
• الطوابع الزمنية للمصدر وطوابع استلام السحابة
• تقسيماً ثابتاً (Partitioning) مناسباً للأصل أو حمل العمل
• معرّفات الرسائل أو أرقام التسلسل لاكتشاف التكرار
• مستهلكين عديمي التأثير (Idempotent) قادرين على التعامل مع التسليم مرة واحدة على الأقل

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

Event Grid يحل مشكلة مختلفة

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

يشمل المشتركون النموذجيون:
• Azure Functions
• Logic Apps
• Webhooks
• سير عمل الأمان
• أنظمة إدارة الأصول
• التطبيقات التشغيلية

الفرق المعماري الجوهري بسيط: يسأل القياس المستمر عما كان الأصل يفعله، بينما يسأل الحدث عما تغير وما إذا كان ينبغي لشيء ما أن يتفاعل.

يجب أن تبدأ الأحداث التحقيقات لا أن تحدد الواقع

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

ينبغي تصميم المعالجات حول:
• المعالجة عديمة التأثير (Idempotent)
• التحقق من الحالة الحالية
• هوية الحدث وطوابعه الزمنية
• ملكية محددة بوضوح للإجراء الناتج

يهم هذا لأن الأحداث المكررة لا ينبغي أن تُنشئ تذاكر مكررة أو تنبيهات مكررة أو سجلات تشغيلية متعارضة.

فصل الجهاز لا يعني توقف الآلة

من أهم الفروق في إنترنت الأشياء الصناعي الفرق بين اتصال السحابة وصحة جمع البيانات وحالة الإنتاج. إذا انفصلت بوابة صناعية عن IoT Hub، فقد فقدت السحابة الرؤية على تلك البوابة. وهذا لا يعني تلقائياً أن الآلة المادية توقفت.

قد تواصل وحدة PLC التحكم في المعدات محلياً بينما تفقد البوابة اتصالها مؤقتاً. وقد يستمر الإنتاج بشكل طبيعي، بل قد تُخزّن البوابة القياسات مؤقتاً وترفعها لاحقاً. ويمكن أن يحدث العكس أيضاً: قد تبقى البوابة متصلة بـ Azure بينما يفشل اتصالها بوحدة PLC أو بالمعدات المحلية.

لذلك تفصل البنية المفيدة بين حالة الاتصال السحابي، وصحة البوابة، وحالة إنتاج الآلة، وحالة أمر العمل في MES. لا يمكن للأعمال تحديد ما إذا كانت مشكلة الاتصال التقنية قد أثرت فعلياً على الإنتاج إلا بدمج هذه المصادر.

التصفية في IoT Hub مقابل التصفية في Event Grid

تدعم التقنيتان التصفية، لكن الغرض مختلف. تجيب تصفية IoT Hub Message Routing عن سؤال: أي الرسائل التشغيلية ينبغي أن تدخل مساراً بيانات محدداً؟ أما تصفية اشتراك Event Grid فتجيب عن سؤال: أي الإشعارات ينبغي أن يتلقاها مشترك بعينه؟

على سبيل المثال، قد تذهب قياسات الإنتاج إلى تدفق Event Hubs واحد، بينما تذهب بيانات الطاقة إلى وجهة أخرى. وفي الوقت نفسه، قد يشترك سير عمل الدعم فقط في أحداث الفصل الصادرة عن جهاز معين.