MQTT vs HTTP vs Modbus TCP vs OPC UA لبوابات IoT الصناعية

يمكن تسليم نفس بيانات الاستشعار بطرق مختلفة

لا يحدد المستشعر السحابة النهائية أو بروتوكول SCADA. RS485 Modbus يتم استخدام RTU بشكل شائع في طبقة الحقل، بينما تقوم البوابة بترجمة تلك البيانات أو إعادة حزمها لطبقة التطبيق. يعتمد البروتوكول الأولي الصحيح على من يبدأ الاتصال، ومكان تخزين البيانات، وما إذا كان يجب إرجاع الأوامر إلى الجهاز، وما هو البرنامج الذي يشغله العميل بالفعل.

MQTT: الأفضل لأنظمة النشر/الاشتراك الموجهة نحو السحابة

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

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

يجب عدم الخلط بين النشر والاشتراك

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

MQTTS والمنفذ 8883

عادةً ما يعني MQTTS MQTT عبر TLS. المنفذ 8883 هو منفذ TLS شائع، لكن الاستخدام الناجح يعتمد على أكثر من رقم المنفذ. يجب أن تكون مكتبة TLS وطريقة التحقق من صحة CA وشهادة الخادم وشهادة العميل الاختيارية وإصدار MQTT متوافقة. في الاختبار الحقيقي للسحابة من جهة خارجية، يمكن للبوابة أحيانًا الاتصال بوسيط TLS واحد ولكنها تفشل مقابل وسيط آخر حتى يتم تحديث البرنامج الثابت.

بالنسبة لمشاريع الإنتاج، اختبر الوسيط الدقيق ووضع الشهادة والبرامج الثابتة قبل شحن دفعة كبيرة. يجب أن تأتي الشهادات من خادم العميل أو النظام الأساسي السحابي أو تتطابق معه؛ فهي ليست ملفات عامة يمكن للشركة المصنعة للبوابة اختراعها بشكل مستقل عن الخادم.

HTTP POST: الأفضل عندما يمتلك العميل نقطة نهاية الويب

غالبًا ما يكون HTTP هو الخيار الأبسط عندما يكون لدى العميل تطبيق خادم يمكنه تلقي طلبات POST. يمكن تكوين البوابة كعميل HTTP وإرسال JSON بشكل دوري إلى عنوان URL المستهدف. يناسب هذا واجهات الويب الخلفية والبيئات المخصصة حيث يفضل فريق البرنامج التعامل المباشر مع الطلب/الاستجابة بدلاً من تشغيل وسيط MQTT.

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

Modbus TCP: الأفضل عندما يجب على SCADA أو PLC الاستعلام عن البيانات

يحمل Modbus TCP نموذج التسجيل Modbus المألوف عبر Ethernet. غالبًا ما يكون مناسبًا عندما يكون نظام PLC أو HMI أو SCADA مصممًا بالفعل باعتباره نظام Modbus الرئيسي. يمكن للبوابة أن تربط أجهزة RS485 Modbus RTU بجانب Ethernet أو تعرض القيم المجمعة من خلال خريطة تسجيل محددة.

إذا قال العميل: "أعطنا عنوان IP وأخبرنا بمكان تخزين كل إشارة؛ وسيقوم نظامنا بقراءتها"، فعادةً ما يكون Modbus TCP أقرب إلى البنية المطلوبة من MQTT أو HTTP.

OPC UA: الأفضل للتكامل الصناعي الأكثر ثراءً

يُستخدم OPC UA على نطاق واسع في البرامج الصناعية لأنه يمكنه تقديم البيانات كعلامات أو عقد مسماة ذات بنية وبيانات تعريفية بدلاً من عناوين التسجيل الرقمية فقط. يمكن أن يكون مناسبًا تمامًا لتطبيقات SCADA والبرامج الوسيطة الصناعية وأجهزة الكمبيوتر التي تحتاج إلى سلوك اكتشاف واشتراك موحد.

لا تدعم كل بوابة OPC UA في نفس الدور، لذا تأكد مما إذا كانت تعمل كخادم OPC UA أو عميل أو كليهما. في مشاريع NiuBoL، يُفضل بوابات الحافة الأكثر قدرة عندما يكون OPC UA مطلبًا أساسيًا.

ما هو البروتوكول الذي يجب عليك اختياره؟

لا يخلط بين بروتوكول الحقل وبروتوكول المنبع

يمكن للنظام استخدام RS485 Modbus RTU من أجهزة الاستشعار إلى البوابة وMQTT من البوابة إلى السحابة في نفس الوقت. يمكنه أيضًا استخدام مستشعرات 4-20 مللي أمبير في بوابة ADC ثم كشف هذه القيم من خلال Modbus TCP أو OPC UA. تعد الواجهة الميدانية وبروتوكول التطبيق بمثابة طبقات تصميم منفصلة.

استكشاف الأخطاء وإصلاحها: MQTT متصل ولكن لا توجد بيانات

1. تأكد من أن طبقة المستشعر تنتج بالفعل بيانات داخل البوابة.
2. تحقق من الفاصل الزمني للتحميل وتأكد من أن البوابة تنشر، وليست متصلة فقط.
3. تحقق من موضوع النشر بدقة، بما في ذلك الخطوط المائلة البادئة وحساسية حالة الأحرف حيث يتعامل معها الوسيط/المنصة بشكل مختلف.
4. استخدم عميل MQTT مستقلًا للاشتراك في نفس الموضوع وعزل البوابة عن منصة الأعمال.
5. تحقق من المصادقة وتضارب معرف العميل وما إذا كان عميل آخر يستخدم نفس بيانات الاعتماد.
6. بالنسبة إلى TLS، تحقق من توافق شهادة CA/الخادم ومكتبات البرامج الثابتة.
7. استخدم سجلات البوابة، وإذا لزم الأمر، التقاط الشبكة لتحديد ما إذا كانت الحزم ستغادر الجهاز وكيفية استجابة الخادم.

استكشاف الأخطاء وإصلاحها: خادم HTTP لا يتلقى أي شيء

أول عملية شراء منفصلة عن التحميل. إذا أشار سجل البوابة إلى أن الجهاز السفلي لا يستجيب، فقم بإصلاح طبقة اتصال المستشعر قبل تصحيح أخطاء الخادم. ثم تحقق من عنوان URL المستهدف والمنفذ وإمكانية الوصول إلى DNS/الشبكة ونوع المحتوى وتنسيق JSON ومتطلبات HTTPS. وظيفة البوابة HTTP في هذه البنية هي عميل يقوم بنشر البيانات بشكل نشط؛ فهو ليس خادم HTTP تلقائيًا ليتصفحه العميل.

الأسئلة الشائعة

Q1: هل MQTT أفضل من HTTP لـIoT؟?

A1: أ1. ولا يوجد أي منهما أفضل على المستوى العالمي. MQTT قوي لأساطيل النشر/الاشتراك؛ يكون HTTP واضحًا ومباشرًا عندما يكون لدى العميل بالفعل نقطة نهاية لاستلام الويب.

Q2: هل يعني MQTT "عبر الإنترنت" أن النظام الأساسي قد تلقى بيانات الاستشعار؟?

A2: أ2. لا. حالة الاتصال بالإنترنت تؤكد الاتصال فقط. لا يزال يتعين التحقق من الموضوع والنشر والاشتراك والحصول على أجهزة الاستشعار.

Q3: ما الفرق بين موضوعات النشر والاشتراك في MQTT؟?

A3: أ3. النشر هو المكان الذي ترسل فيه البوابة بيانات القياس عن بعد؛ الاشتراك هو المكان الذي تستمع فيه البوابة إلى الرسائل أو الأوامر من خادم إلى جهاز.

Q4: هل يمكن لبوابة IoT إرسال JSON عبر HTTP POST؟?

A4: نعم، على البوابات/البرامج الثابتة التي تدعم تحميل عميل HTTP. وافق على بنية JSON الدقيقة ومعالجة الاستجابة مع فريق الخادم.

Q5: هل المنفذ 8883 مدعوم دائمًا لـMQTTS؟?

A5: أ5. 8883 هو أمر شائع، ولكن يجب أن يكون البرنامج الثابت للبوابة ووضع شهادة TLS متوافقين مع الوسيط المستهدف. يجب أن يوثق ملف تشغيل MQTT vs HTTP vs Modbus TCP vs OPC UA لبوابات IoT الصناعية النطاق المتفق عليه واستجابة الإنذار وفحص الواجهة ودليل الصيانة المطلوب للتسليم.

Q6: متى يجب علي استخدام Modbus TCP بدلاً من MQTT؟?

A6: أ6. استخدم Modbus TCP عندما يتعين على سيد صناعي مثل PLC أو SCADA الاستعلام عن السجلات بشكل نشط عبر Ethernet. يجب أن يوثق ملف تشغيل MQTT vs HTTP vs Modbus TCP vs OPC UA لبوابات IoT الصناعية النطاق المتفق عليه واستجابة الإنذار وفحص الواجهة ودليل الصيانة المطلوب للتسليم.

Q7: متى يكون OPC UA مفضلاً؟?

A7: أ7. استخدم OPC UA عندما تستفيد البرامج الصناعية من العلامات/العقد القياسية وبيانات التعريف وإمكانية التشغيل البيني الأكثر ثراءً.

Q8: هل يمكن لبوابة واحدة استخدام أكثر من بروتوكول رئيسي؟?

A8: أ8. يمكن للعديد من بوابات الحافة القيام بذلك، ولكن يجب التحقق من السلوك المتزامن متعدد الوجهات للبرنامج الثابت والمشروع المحددين.

الخلاصة