توجيه رسائل إنترنت الأشياء الصناعي: تجنب فخ ازدحام الأحداث

By Mirko Peters · 2026-10-02

اكتشف لماذا لا يتشابه توجيه الرسائل في Azure IoT Hub مع Event Grid. تعرّف على كيفية تصميم بنى إنترنت الأشياء الصناعي دون التسبب في ازدحام الأحداث.

Automatically translated with AI from the original post. Read the English original

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

النقاط الرئيسية

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

فخ المعمارية المتمثل في معاملة كل شيء كحدث

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

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

لماذا تفشل محركات الإشعارات مع بيانات السلاسل الزمنية

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

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

توجيه رسائل IoT Hub بوصفه مستوى بيانات القياس عن بُعد

لبناء أساس موثوق للتحليلات ومراقبة الحالة، يجب التعامل مع القياس عن بُعد بوصفه سجلًا إنتاجيًا ذاتي الكتابة. يوفّر Azure IoT Hub حدّ الاتصال الآمن من الجهاز إلى السحابة، حيث تُصادق البوابات الصناعية بهويات فريدة، وتبث البيانات الخام من الجهاز إلى السحابة، وتدير التوائم الرقمية للأجهزة (device twins).

يعمل توجيه الرسائل (Message Routing) بوصفه المتحكم المركزي في حركة المرور على مستوى البيانات هذا. فمن خلال فحص خصائص الرسائل وبيانات النظام الوصفية ومحتوى الحمولة، تفصل قواعد التوجيه بوضوح مقاييس الإنتاج وتشخيصات الطاقة والقياسات التشغيلية قبل وصولها إلى المستهلكين اللاحقين. فعلى سبيل المثال، يمكن لبوابة صناعية واحدة أن تبث الحمولات الخام إلى Azure Event Hubs أو Azure Storage، لتغذية Microsoft Fabric ولوحات Power BI، دون أن تُجبر كل قراءة فردية على تفعيل سير عمل تشغيلي فوري.

إدارة انقطاعات الشبكة والطوابع الزمنية

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

يفرض ذلك متطلبًا معماريًا بالغ الأهمية، وهو التمييز بين الطابع الزمني للمصدر (لحظة التقاط PLC أو المستشعر لقراءة الاهتزاز) والطابع الزمني لاستلام السحابة (لحظة استيعاب IoT Hub للدفعة في النهاية). يعتمد خط أنابيب القياس الموثوق على التقسيم المستقر، ومعرّفات الرسائل غير القابلة للتغيير، وأرقام التسلسل، والمستهلكين المُحصّنين ضد التكرار (idempotent)، لإعادة بناء الواقع بدقة، بما يضمن ألا تُفسد الحزم المتأخرة حسابات مثل الفعالية الكلية للمعدات (OEE).

فصل صحة الاتصال بالسحابة عن حالات الإنتاج

من أخطر الأنماط المضادة في الأتمتة الصناعية افتراضُ أن انقطاع الاتصال بالسحابة يعني توقف الآلات المادية عن العمل. فعندما تنفصل بوابة صناعية عن Azure IoT Hub، يصدر Azure Event Grid إشعار فقدان الجهاز (device-disconnected) بحق، لتنبيه فرق الدعم في تقنية المعلومات والتقنيات التشغيلية.

غير أن حدث الانفصال لا يثبت سوى أن رؤية السحابة قد تغيّرت. فخلف البوابة المنفصلة، قد يواصل وحدة التحكم المنطقي القابلة للبرمجة (PLC) المحلية تشغيل خط المكابس بصورة مستقلة، فينتج قطعًا معدنية دون أن يتوقف. وعلى العكس، قد تحافظ بوابة ما على اتصال TCP سليم مع Azure، بينما تكون وصلتها التسلسلية (serial) بالآلة المحلية قد تعطلت تمامًا.

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

الخلاصة والخطوات التالية

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

بإبقاء هذين المسارين منفصلين، تتجنب تضخم البنية المعمارية، وتقضي على الإنذارات الكاذبة المزعجة، وتحافظ على سجل تشغيلي موثوق لمؤسستك بأكملها.

للتعمق أكثر في سيناريوهات التصنيع الصناعي، وحدود التشغيل، وأفضل ممارسات بنية السحابة، استمعوا إلى الحلقة كاملةً واشتركوا في بودكاست M365 FM اليوم.

الأسئلة المتداولة

هل يمكن استخدام Azure Event Grid لتخزين بيانات القياس عن بُعد عالية التردد من أجهزة إنترنت الأشياء؟

لا. صُمّم Event Grid لإشعارات النشر والاشتراك الخفيفة، وليس لاستيعاب البيانات بحجم كبير. فهو يفتقر إلى الاستبقاء الأصلي للسلاسل الزمنية، وإمكانات إعادة التشغيل، وضمانات الترتيب الصارمة اللازمة للتحليلات الدقيقة في التصنيع.

ماذا يجب أن يحدث عند إطلاق حدث فصل الجهاز في Azure IoT Hub؟

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

كيف تستهلك أدوات التحليلات اللاحقة مثل Microsoft Fabric بيانات القياس من IoT Hub؟

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

لماذا يُعد ترتيب الرسائل بالغ الأهمية لبيانات القياس الصناعية؟

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