وُجد LLRP، أي بروتوكول القارئ منخفض المستوى، لأن كل قارئ UHF ثابت كان يتحدث لغة مختلفة. قبل ذلك كان دمج ثلاثة مصنّعين يعني ثلاث حزم تطوير وثلاث دلالات اتصال وثلاث طرق للتعبير عن "اقرأ هذه الهوائيات الأربعة بهذا المرشّح". يستبدل LLRP ذلك ببروتوكول ثنائي واحد فوق TCP.
ما الذي يوحّده LLRP فعليًا
يعرّف LLRP الرسائل التي يرسلها العميل إلى القارئ والتقارير التي يعيدها القارئ: اكتشاف القدرات، وتهيئة القارئ، ومواصفات الجرد والوصول، وأوامر الوصول إلى الوسم، وإشعارات الأحداث. لا تزال النسخة 1.0.1 المعتمدة عام 2007 هي الأوسع انتشارًا، وتضيف النسخة 2.0 أوامر Gen2 v2.
لكنه لا يوحّد منطق عملك ولا نموذج بياناتك ولا تسمية هوائياتك. تلك تبقى مسؤوليتك، والخلط بين البروتوكول والتكامل هو النقطة التي تنحرف عندها معظم المشاريع.
- اكتشاف القدرات: عدد الهوائيات ونطاق القدرة وبروتوكولات الهواء المدعومة.
- التهيئة: وضع التردد والقدرة المرسلة وأوزان الهوائيات وسلوك GPI وGPO.
- الجرد: تحدد ROSpec وAISpec أي الهوائيات تعمل وما يُبلَّغ عنه.
- الوصول: عمليات القراءة والكتابة والقفل والقتل على مجموعة أوسمة مختارة.
أي إعدادات يجب أن تعيش في الوسيط لا في البرنامج الثابت
كل ما يختلف بين موقعين يجب أن يوضع في الوسيط، ويُدار بإصدارات في نفس مستودع التكامل. أما القيم الافتراضية على القارئ فهي غير مرئية وغير مُصدَّرة وغير قابلة للتدقيق بعد رحيل المهندس الذي ضبطها.
- جلسة الجرد وهدف القراءة وتقدير عدد الأوسمة.
- القدرة المرسلة لكل هوائي، وربط الهوائي بالمنطقة.
- المرشّحات (بادئة EPC وقناع TID) التي تحدد ما يُسمح للقارئ بالإبلاغ عنه.
- وضع القارئ: أقصى إنتاجية أو القارئ الكثيف أو الوضع المختلط.
- محفزات GPI ونوافذ مقاومة الاهتزاز لحساسات الناقل أو الباب.
كيف تُنمذج ROSpec وAISpec وAccessSpec؟
ROSpec هو الحاوية: يجمع الهوائيات ومواصفة جرد ومواصفة وصول اختيارية ومواصفة تقرير، وينتقل بين حالات التعطيل وعدم النشاط والنشاط. تحدد AISpec أي الهوائيات تعمل بأي معاملات جرد، وتحدد AccessSpec ما يُقرأ أو يُكتب على الأوسمة المطابقة للمرشّح.
أبقِ ROSpec واحدًا لكل منطقة فيزيائية، لا لكل هوائي. بذلك يصبح باب الرصيف كائنًا واحدًا يمكنك تشغيله وإيقافه ومراقبته، ويبقى ربط الهوائيات تفصيل تهيئة بدلًا من تعديل في الكود.
- ROSpec واحد لكل منطقة: باب الرصيف، خط الإنتاج، المخزن.
- فاصل تقرير من 200 إلى 1000 مللي ثانية للبوابات؛ والإبلاغ الفوري للقراءات منخفضة الحجم فقط.
- AccessSpec للكتابة فقط؛ وأبقِ مناطق القراءة فقط خالية من أوامر الوصول.
أين تفشل مشاريع LLRP عادة؟
البروتوكول نادرًا ما يكون المشكلة، فالإخفاقات تشغيلية.
- معالجة الاتصال: القارئات تعيد التشغيل وتفقد TCP وتعيد الاتصال بأمواج؛ والعميل بلا تراجع أسّي يرهق القارئ والشبكة معًا.
- القراءات المكررة: رؤية الوسم نفسه اثنتي عشرة مرة في ثانيتين حدث واحد وليست اثنتي عشرة حركة مخزون.
- فيضان المخازن المؤقتة: دفعة من 800 وسم عند بوابة تُغرق عميلًا يعالج بشكل متزامن.
- تفاوت البرامج الثابتة: الحقول والقدرات الاختيارية تختلف بين الطرازات والإصدارات، لذا تُعامل نتائج الاكتشاف كبيانات لا كافتراضات.
- غياب فصل المسؤوليات: القواعد التجارية المدفونة في تهيئة القارئ لا يمكن اختبارها.
كيف يجب أن تصل الأحداث إلى Odoo؟
المسار النظيف هو: حدث القارئ، ثم التطبيع، ثم إزالة التكرار، ثم الحدث التجاري، ثم نداء ERP. لكل خطوة مسؤولية واحدة ويمكن تسجيلها مستقلًا.
- حدث القارئ: EPC والهوائي والطابع الزمني وعدد القراءات وRSSI.
- التطبيع: EPC إلى منتج، والهوائي إلى موقع، والقارئ إلى نوع العملية.
- إزالة التكرار: نافذة مقاومة اهتزاز من 3 إلى 10 ثوانٍ لكل EPC ومنطقة.
- الحدث التجاري: استلام أو نقل أو جرد أو تسوية، واحد لكل حركة فيزيائية.
- نداء Odoo: تحديث stock.quant أو إنشاء stock.move أو تسوية مخزون، بمفتاح عدم تكرار مبني من EPC والمنطقة والنافذة الزمنية.
كيف تبدو المراقبة والتحويل عند الفشل؟
تعامل مع القارئات كأجهزة شبكة. استعلم عن نبضة الحياة وحالة GPI كل 30 ثانية، وأنذر عند انهيار معدل القراءة لا عند الأخطاء الفردية، وخزّن الأحداث محليًا عندما يتعذر الوصول إلى ERP أو الشبكة.
التخزين وإعادة الإرسال ليس اختياريًا في مستودع تتحول فيه قراءة مفقودة عند باب الرصيف إلى فرق مخزون بعد ثلاثة أسابيع. اجعل سعة التخزين تغطي أربع ساعات على الأقل بمعدل الذروة، وأعد الإرسال بأوقات الحدوث الأصلية كي يرى ERP التسلسل الصحيح.
الخلاصة
يمنحك LLRP بروتوكولًا واحدًا لقارئات متعددة المصنّعين، وهذا كل ما يمنحه. ضع التهيئة والتصفية والتخزين المؤقت في الوسيط، ونمذج ROSpec واحدًا لكل منطقة، وأزل التكرار قبل لمس ERP، وراقب القارئات كأجهزة شبكة كما هي فعلًا.
