اختبار سعة بوابة BLE متعددة الحساسات وإعادة اتصالها

تحتاج إجابة سؤال «كم حساس BLE تستطيع بوابة واحدة دعمه؟» إلى وصف حمل العمل. فعشرة حساسات ترسل مرة كل دقيقة تمثل مشكلة مختلفة عن عشرة أجهزة ترسل دفعات كل 20 ملي ثانية. تحدد مواصفة السعة القابلة للدفاع عنها حدود الراديو والبرمجيات، وتثبت حداثة البيانات تحت الحمل المطلوب، وتقيس التعافي عند اختفاء عدة حساسات معًا.

اختيار الجمع عبر اتصال أو عبر الإعلانات

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

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

تصف حالة بوابة ESP32 Wi-Fi وBluetooth المُسلَّمة اتجاهين مختلفين، أحدهما Wi-Fi والآخر SIG Mesh. وهي مفيدة لفهم البنية، لكنها لا تقدم سعة مقاسة لحساسات GATT المتصلة. تحتاج بوابة GATT إلى تحقق مستقل من الأجهزة الطرفية وحمل العمل.

فصل حدود الاتصالات الصلبة عن السعة القابلة للاستخدام

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

كمثال محدد الإصدار، يسرد دليل الاتصالات المتعددة لـESP32 في ESP-IDF v6.0.3 من Espressif تسعة اتصالات متزامنة لكل من ESP-NimBLE وESP-Bluedroid، مع إعدادات المضيف المقابلة وإعداد متحكم مطابق. هذا سقف للتنفيذ، وليس عدد حساسات مضمونًا لكل حمل أو لكل شريحة من عائلة ESP32. ويتيح Zephyr أيضًا CONFIG_BT_MAX_CONN. راجع وثائق الإصدار الفعلي للمنتج. المصادر: دليل الاتصالات المتعددة من Espressif ووثائق صدفة GAP في Zephyr.

في بوابة Linux، لا تثبت إضافة RAM أو معالج أسرع ارتفاع حد متحكم الراديو. سجّل طراز متحكم USB/UART وبرنامجه الثابت والنواة وإصدار BlueZ. اجعل استدعاءات الإشعار الراجعة قصيرة: تحقّق من البيانات وأدخلها الطابور، ثم نفّذ الكتابة إلى قاعدة البيانات والعمل على الوصلة الصاعدة خارج مسار الاستدعاء الراجع للبلوتوث.

بناء ميزانية مرور بهامش مقاس

احسب بايتات التطبيق أولًا. فمثلًا، ثمانية حساسات ينتج كل منها سجلًا من 16 بايت بمعدل 5 Hz تولّد 640 بايت في الثانية قبل أعباء البروتوكول. هذا الحساب ليس توقعًا لمعدل النقل اللاسلكي. فتبادل الحزم وأحداث الاتصال الفارغة والإقرارات وإعادات الإرسال والمسح والجدولة تستهلك وقتًا إضافيًا.

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

قِس فاصل الاتصال المتفاوض عليه وزمن تأخر الجهاز الطرفي ومهلة الإشراف وPHY وATT MTU وطول بيانات طبقة الربط. لا تضمن ATT MTU الأكبر حزمة أطول على طبقة الربط ولا عددًا أكبر من الحزم في كل حدث. قد تسهّل زيادة فاصل الاتصال الجدولة، لكنها قد تزيد التأخير أو احتياج تخزين الدفعات. غيّر المعلمات وفق هدف حداثة البيانات، لا وفق إعداد عام باسم «أقصى معدل نقل».

تنفيذ إعادة الاتصال كآلة حالات محدودة

تتبّع كل حساس على حدة عبر الاكتشاف والاتصال والأمان وحلّ الخدمات والاشتراك والتدفق. «متصل» لا تعني «جاهز». من معايير الجاهزية المفيدة استلام أول عينة تطبيق صالحة ومحددة الهوية بصورة صحيحة بعد الاشتراك.

DISCOVER -> CONNECT -> SECURE -> RESOLVE -> SUBSCRIBE -> STREAM
failure  -> RELEASE_RESOURCES -> BACKOFF -> DISCOVER

# Illustrative full-jitter backoff, seconds:
delay = random_uniform(0, min(60, 2 ** min(attempt, 6)))
# Reset attempt after a defined healthy-stream interval.
# Limit simultaneous connection/setup attempts globally.

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

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

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

اختبار التنافس والأعطال أثناء انشغال جميع الروابط

في تصميم ذي راديو مشترك، يتنافس جمع BLE ومرور Wi-Fi على الموارد اللاسلكية. توثق Espressif تعايشًا قائمًا على الأولوية وتغيّر الجدولة بحسب حالة Wi-Fi. اختبر الوصلة الصاعدة المستقرة وكذلك مسح Wi-Fi وإعادة اتصاله؛ فالاتصال الهادئ على منصة الاختبار لا يغطي هذه الظروف. راجع دليل تعايش ESP32، ثم الدليل المقابل لإصدار SDK والشريحة المختارين.

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

تعريف القبول من خلال البيانات القابلة للاستخدام

حدّد عتبات النجاح قبل الاختبار. قد تتطلب مواصفة توضيحية أن يكون المئين 99 لعمر العينة أقل من ثانيتين، وأن تتحقق نسبة محددة لتسليم العينات الفريدة، وأن تُستعاد جميع الحساسات القابلة للوصول ضمن نافذة تعافٍ متفق عليها. هذه أمثلة متطلبات وليست نتائج مقاسة معلنة. يحتاج حساس بطيء بعينة كل دقيقة إلى هدف حداثة مختلف.

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

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

تشخيص الطبقة التي تعطلت فعلًا

• تتصل الروابط لكن لا تصل بيانات: افحص حلّ الخدمات وحالة الاشتراك والأذونات وحالة توليد البيانات في الحساس.
• يحدث الفشل فقط عند الأعداد الأكبر: افحص حدود المتحكم ونفاد المخازن وجدولة الأحداث وتزامن الإعداد على مستوى النظام.
• يلي الفشل نشاط الوصلة الصاعدة: قارن سجلات تعايش Wi-Fi ومدة الاستدعاء الراجع ونمو الطابور.
• يؤخر حساس معطوب جميع الأجهزة الأخرى: افحص الأقفال المشتركة والمحاولات المتسلسلة غير المحدودة وإنصاف الطوابير.
• لا تنجح إعادة الاتصال إلا بعد إعادة التشغيل: افحص كائنات الاتصال المتسربة والاستدعاءات القديمة والحالات التي لا تملك مخرجًا عند انتهاء المهلة.

يتضمن ملف المشروع المفيد عينات الحساسات وإصدارات البرامج الثابتة وملفات أحمال المرور والطوبولوجيا وسلوك الوصلة الصاعدة وأهداف القبول الرقمية. تمثل خدمة تكامل البوابات من Obeita مدخلًا مناسبًا لتحديد نطاق العمل. ينبغي أن يكون التسليم نطاق سعة موثّق الإصدار وتقرير تعافٍ للتهيئة المختارة، مع سجلات تدعم النتائج. وللسياق المعماري، راجع حالة بوابة ESP32 Wi-Fi وBluetooth المُسلَّمة ذات الصلة. الأمثلة الرقمية وخطة الاختبار هنا ليست نتائج مقاسة من تلك الحالة.