تبدأ معظم مشاريع RFID بقارئ واحد يكتب في قاعدة بيانات واحدة، وتنتهي بأربعين قارئًا يكتبون في القاعدة نفسها بسرعة أكبر. الجزء المثير للاهتمام هو المسافة بين الحالتين، وهو لا يتعلق تقريبًا أبدًا بالوسيط الذي ثبّته.
لماذا يناسب MQTT تدفقات أحداث RFID
ينتج أسطول RFID تدفقًا حادًا وأحادي الاتجاه وعالي الحجم من رسائل صغيرة، ولهذا الشكل نتائج.
- الأحداث صغيرة ومتكررة؛ واستدعاء REST لكل وسم يهدر ثلاثة أُسّ من الموارد.
- القارئات تعمل على شبكات صناعية غير موثوقة، لذا يجب أن يتحمّل النقل إعادة الاتصال دون فقدان الحالة.
- الناشر لا يعرف شيئًا عن المستهلك، ويجب أن يبقى كذلك؛ القارئات لا تحمل منطق ERP.
- تمنح الموضوعات تقسيمًا طبيعيًا حسب الموقع والمنطقة والجهاز، وهي أيضًا طريقة توسيع المستهلكين.
- يحتفظ MQTT بجلسة دائمة، فيستطيع المشترك بعد إعادة الاتصال استرجاع ما فاته.
النقطة الأخيرة هي ما يعتمد عليها الجميع، وما يُعدّونه خطأً في الغالب.
العقد هو التكامل، لا الوسيط
الوسطاء سلع جاهزة. مخطط الحدث هو الأصل، ويستحق انضباطًا كالذي تستحقه جدول قاعدة بيانات.
- ضع رقم الإصدار داخل جسم الرسالة من اليوم الأول، لا في اسم الموضوع.
- ثبّت حقول الهوية: معرّف الجهاز، رمز الموقع، الهوائي، وقت القراءة بتوقيت UTC، EPC، شدة الإشارة، ورقم تسلسلي متزايد.
- حدّد معنى «قراءة»: حدث هوائي واحد أم نافذة رصد بعد إزالة التكرار.
- قرّر أين تُربط الدلالة التجارية: القارئ يبلّغ بالوقائع، والمشترك يفسّرها.
- اكتب المخطط وولّد منه أنواع الناشر والمشترك.
إذا كان موقعان يستطيعان إنتاج أسماء حقول مختلفة لنفس الواقعة، فأنت لا تملك تكاملًا واحدًا، بل تكاملين يشتركان في وسيط بالمصادفة.
المشترك يعمل خارج عمليات الطلبات
أشهر عطل إنتاجي معماري لا تقني: المشترك مركّب داخل العملية نفسها التي تخدم طلبات الويب.
- عمليات ويب في Odoo قصيرة العمر ويُعاد تدويرها؛ والاشتراك الطويل لا ينتمي إليها.
- شغّل خدمة مستقلة بإشراف عملياتي وميزانية ذاكرة وسياسة إعادة تشغيل خاصة بها.
- أعطها اتصال قاعدة بيانات منفصلًا عن مجموعة اتصالات المستخدمين، بمهل تنفيذ خاصة.
- لا تدع معالج الحدث يبقي المعاملة مفتوحة بانتظار الرسالة التالية أبدًا.
- انشرها بخط النشر نفسه الخاص بالتطبيق، لكن بإيقاع إصدار مستقل عند الحاجة.
المشترك الذي يموت حين يرفع مستخدم ملفًا كبيرًا ليس مشتركًا، بل رهينة.
جودة الخدمة والتكرار وفخ الرسالة المحتفظ بها
تُختار مستويات الخدمة بالعادة، فتنتج أحداثًا مفقودة وحركات مخزون مكررة في الوقت نفسه.
- مستوى 0 يفقد الرسائل عند إعادة الاتصال؛ مقبول للقياس، غير مقبول لحركات المخزون.
- المستوى 1 يضمن الوصول ويسمح بالتكرار صراحةً؛ لذا يجب أن يكون المعالج متماثلًا.
- المستوى 2 يزيل التكرار على مستوى البروتوكول لكنه يكلّف رحلات ذهاب وعودة ونادرًا ما يستحق هنا.
- الرسائل المحتفظ بها للحالة الأخيرة المعروفة لا للتاريخ؛ لا تحتفظ بحركة مخزون أبدًا.
- الجلسات النظيفة تُسقط القائمة عند إعادة الاتصال؛ وإن احتجت الاسترجاع فاستخدم جلسة دائمة ومعرّف عميل ثابتًا.
اختر المستوى 1 مع معالج متماثل، وأنفق جهدك على المعالج.
التماثل والترتيب وانضباط الساعة
قد يصل حدثان عن المنصة نفسها خارج الترتيب، أو مرتين، أو كليهما.
- ابنِ مفتاح التماثل من الجهاز وEPC والهوائي ووقت القراءة، وأسنِده بفهرس فريد.
- لا تثق بساعات الأجهزة؛ خزّن وقت الاستقبال ووقت الإبلاغ معًا.
- عالج الوصول غير المرتّب بمقارنة طوابع وقت الحدث، لا بترتيب الوصول.
- للتسويات، اكتب سجل أحداثًا للإضافة فقط واستنتج الرصيد، بدلًا من تعديل كمية في مكانها.
- اجعل الإعادة آمنة بالتصميم، فيجرؤ المشغّل على إعادة تشغيل دفعة الليلة الماضية دون خوف.
المخزون الذي لا يُصحّح إلا يدويًا هو المخزون الذي يُصحّح يدويًا كل أسبوع.
الضغط الخلفي والدفعات وقائمة الرسائل الميتة
المشترك الذي يواكب يوم ثلاثاء هادئًا سيتخلّف في جرد كامل.
- جمّع الكتابات في دفعات صغيرة بفاصل تفريغ محدود، فيرتفع الإنتاج دون إطالة الكمون.
- طبّق الضغط الخلفي عمدًا: أبطئ مجموعة المستهلكين، ولا تُسقط بصمت أبدًا.
- وجّه الرسائل الفاسدة إلى موضوع رسائل ميتة مع الحمولة الأصلية وسبب الفشل.
- نبّه على نمو هذا الطابور، فالطابور الصامت مكان اختباء فقدان البيانات.
- حُدّ المحاولات مع تراجع أُسّي، ثم أوقف الرسالة لمراجعة بشرية.
قائمة الرسائل الميتة ليست إقرارًا بالفشل؛ إنها الفرق بين ظهيرة سيئة ودفتر أستاذ تالف.
الأمن وعزل المستأجرين بين المواقع
وسيط مفتوح داخل شبكة مصنع هو أداة للتلاعب بالمخزون لكل من يجده.
- أنهِ TLS عند الوسيط، ووثّق كل جهاز ببيانات اعتماد خاصة لا بكلمة مرور مشتركة.
- رخّص الموضوعات، فلا ينشر قارئ في المستودع A داخل نطاق المستودع B.
- أبقِ الحمولات خالية من البيانات الشخصية قدر الإمكان؛ وإن ارتبط وسم بشخص فشفّر ذلك الربط أو رمّزه.
- دوّر بيانات الاعتماد وفق جدول وعند إخراج الجهاز من الخدمة، وسجّل كل تدوير.
- افصل على مستوى قاعدة البيانات بين صلاحيات القراءة والكتابة للمشترك.
القابلية للمراقبة: إثبات أن السلسلة حيّة
السؤال في الثالثة فجرًا ليس «هل الوسيط يعمل»، بل «هل وصلت قراءات الساعة الأخيرة إلى Odoo».
- تتبّع عمر الرسالة من طرف إلى طرف: وقت النشر ناقص وقت التثبيت، مع عتبة تنبيه.
- أرسل نبضة لكل جهاز ونبّه حين يصمت جهاز في ساعات التشغيل.
- أحصِ المستلم والمعالج والمنزوع التكرار والمرفوض، واعرض الأرقام الأربعة معًا.
- احتفظ بمهمة مطابقة تقارن عدد الأحداث بحركات المخزون الناتجة في الساعة الأخيرة.
- سجّل معرّف ربط من القارئ إلى سجل Odoo، فتُتتبّع قراءة متنازع عليها في دقائق.
لا شيء من هذا غريب. إنه الانضباط العادي في التعامل مع خط أحداث كنظام مالي، لأنه يصبح كذلك في اللحظة التي يعتمد فيها المخزون عليه.
