من مثال LoRa لمسافة 6 كم إلى FUOTA موثوقة: المدى ووقت البث وDelta OTA في بستان اليوسفي

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

ملخص

تبدو المشكلة بسيطة للوهلة الأولى: هل تستطيع عقدة استشعار تعتمد على LoRa إرسال البيانات من بستان يوسفي إلى بوابة؟ عند وصول المنتج إلى الحقل يظهر سؤال أصعب: كيف نوزع مئات الكيلوبايتات من البرنامج الثابت بشكل موثوق عبر الاتصال نفسه؟

تبدأ هذه الدراسة من قيمة تقريبية تبلغ 6 كم عند SF9/125 kHz وردت في الملخص التقني لشركة Semtech. ثم تشرح لماذا لا يمكن نقل هذه القيمة مباشرة إلى بستان يوسفي كثيف، وتتناول المفاضلة بين المدى ومعدل نقل البيانات التي يحددها spreading factor (SF) وbandwidth (BW). كما توضح أن link budget لا يعني جمع قدرات الإرسال لجهازين؛ بل يجب تقييم المرسل النشط وحساسية المستقبل المقابل وكسب الهوائيات وخسائر البيئة معاً. بعد ذلك نختار بستان اليوسفي من بين عدة بيئات زراعية ونناقش ارتفاع الهوائي. وفي النهاية نقترح Delta OTA بدلاً من الصورة الكاملة، وتحديثات متعددة المراحل، واختيار مسار delta على الخادم.

النتيجة الأساسية واضحة: نجاح FUOTA لا يتوقف على العثور على أطول مدى فقط. يجب تصميم سعة downlink الموثوقة ووقت البث الكلي وduty cycle وفقدان الحزم وموقع البوابة والتحقق من bootloader وتنسيق التحديث معاً.

1. لماذا لا يمثل مثال Semtech التقريبي لمسافة 6 كم مدى حقيقياً في البستان؟

يعرض الملخص التقني لـ LoRa من Semtech مثالاً يبلغ نحو 6 كم عند SF9/125 kHz. ويشير المستند نفسه إلى أن قيم المدى تعتمد على التضاريس (Semtech, LoRa and LoRaWAN: A Technical Overview). هذه القيمة مرجع لإعداد تعديل محدد وظروف مثالية في منطقة مفتوحة، وليست ضماناً لمدى موثوق ثنائي الاتجاه في بستان يوسفي.

الأسباب الرئيسية هي:

1. الانتشار مع خط رؤية في أرض مفتوحة يختلف عن انتشار NLOS بين صفوف الأشجار.
2. هوائي الحساس القريب من الأرض يختلف عن هوائي البوابة المرتفع المستخدم في اختبار كتالوج.
3. يعتمد مدى الشركة المصنعة على SF/BW وحجم حزمة وهوائي وقدرة محددة.
4. يجب أن يتضمن المدى القابل للاستخدام الاتجاه الأضعف في الوصلة ثنائية الاتجاه ومعدل نجاح الحزم المستهدف.
5. تتغير الرطوبة والمطر والري وكثافة الأوراق واتجاه الصفوف خلال الموسم.

درست أبحاث ميدانية في بساتين اليوسفي وغيرها تأثير الأوراق والأغصان والجذوع وهندسة الصفوف وارتفاع الهوائيات على فقدان المسار (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards؛ citrus orchard RF deployment study). لذلك يمكن أن تكون قيمة 6 كم في جدول Semtech فرضية أولية للقياسات الميدانية، لكنها ليست النتيجة.

وهكذا يتغير السؤال المركزي:

إلى أي link margin ومعدل نجاح للحزم ووقت بث FUOTA تتحول قيمة Semtech المرجعية البالغة 6 كم في منطقة مفتوحة داخل بستان يوسفي كثيف؟

2. كيف يغير SF وBW المدى؟

في الطبقة الفيزيائية لـ LoRa، يحدد spreading factor مدى توزيع البيانات على رموز chirp. يوضح الملخص التقني لـ Semtech أن رفع SF ضمن المجال SF7–SF12 يحسن حساسية المستقبل، لكنه يخفض bit rate وسرعة نقل البيانات (Semtech, LoRa and LoRaWAN: A Technical Overview).

يمكن تلخيص العلاقة كالتالي:

جدول رقمي لـ SF وBW والمدى في بستان اليوسفي

الجدول التالي هو تقدير هندسي للتخطيط في بستان حمضيات يبلغ ارتفاعه نحو 2.5–4 أمتار، بأوراق كثيفة ومروية وموجودة طوال العام. تعرض الخلايا الصيغة المدى (m) / PHY bit rate الإجمالي (kbit/s)؛ وينبغي اعتماد الحد الأدنى للنطاق عند تصميم نظام موثوق. يفترض سيناريو الحساب استخدام E22-900M22S/SX1262، وتردد 868 MHz، وCR 4/5، وكسب هوائي قدره 0 dBi، وخسائر قدرها 2 dB للكابل والموصلات، وهامش إضافي قدره 10 dB للتلاشي والسلامة، وهوائياً غير مدفون في التربة (معلومات الشركة المصنعة لـ E22-900M22S).

يُحسب PHY bit rate من العلاقة R_b = SF × (BW / 2^SF) × 4/5 ولا يمثل throughput الفعلية للتطبيق. وتخفض ترويسات LoRaWAN وduty cycle ووقت الانتظار وإعادة المحاولات وبيانات التجزئة الوصفية وفقدان الحزم السرعة المفيدة أكثر. المديات المذكورة تقديرات تخطيطية مبنية على افتراضات RF أعلاه، وليست قياسات ميدانية أو قيماً مضمونة لبستان اليوسفي. عمودا SF5–SF6 وBW250/BW500 هما للمقارنة باستخدام LoRa الخام؛ ويجب التحقق بشكل منفصل من التركيبات الخارجة عن معدلات بيانات LoRaWAN القياسية في EU868 مقابل المعلمات الإقليمية.

تحدد المعلمات الإقليمية لـ LoRaWAN خطط القنوات ومعدلات البيانات المسموح بها وحدود القدرة والقيود الإقليمية. لذلك يجب التحقق من جدول SF/BW مقابل معلمات البلد والنطاق المستخدم (LoRa Alliance RP002 Regional Parameters؛ وتتوفر القائمة الحالية في LoRa Alliance Technical Committee Publications).

لماذا يهم ADR؟

يسمح LoRaWAN Adaptive Data Rate (ADR) لـ network server بضبط data rate وقدرة إرسال الجهاز وفق جودة الوصلة. وتصف Semtech الهدف بالحفاظ على link margin المطلوب مع استخدام data rate أعلى لتقليل airtime واستهلاك سعة الشبكة (Semtech, Understanding LoRa Adaptive Data Rate).

وبالنسبة إلى FUOTA، فالنتيجة واضحة: لا ينبغي للجهاز الانتقال إلى SF12 إلا عند الحاجة الفعلية. فإذا كانت الوصلة موثوقة عند SF9 أو SF8، فإن SF الأقل قد يقلل زمن التحديث.

3. Link budget: لا تُجمع قدرات الجهازين

لا يمكن جمع قدرات خرج Dragino وE22 ببساطة في حساب واحد. يجب حساب كل اتجاه RF على حدة:

القدرة المستقبلة =
قدرة خرج المرسل النشط
+ كسب هوائي الإرسال
+ كسب هوائي الاستقبال
− خسائر الكابل والموصلات
− فقدان الانتشار
− خسائر الأوراق والجذوع والأرض والعوامل البيئية الأخرى

في اتجاه E22 → Dragino، نستخدم قدرة خرج E22 وحساسية مستقبل Dragino. وفي اتجاه Dragino → E22، نستخدم قدرة Dragino وحساسية E22. يحدد الاتجاه الأضعف المدى ثنائي الاتجاه القابل للاستخدام. وبما أن الحساسية تتغير مع SF وBW وcoding rate وظروف القياس، فإن إعطاء رقم واحد لـ “مدى الجهاز” غير مكتمل تقنياً. يشرح ملخص Semtech التقني لـ LoRa العلاقة بين معلمات التعديل والحساسية وbit rate.

في حسابات الحقل لهذه المقالة، لا تفترض قيمة اسمية بوحدة dBm قبل تثبيت طرازي Dragino وE22 ونوع الهوائي والقدرة المقاسة عند الخرج والتراخيص الإقليمية. لا تغني أوراق البيانات عن القياسات الميدانية.

4. لماذا نعامل نوع المحصول كمشكلة RF مستقلة؟

لا ينتج إعداد الراديو نفسه النتيجة نفسها في كل بيئة زراعية. يمكن للأوراق والأغصان والجذوع ورطوبة التربة وهندسة الصفوف والمطر أن تؤثر في التشتت والامتصاص والتلاشي متعدد المسارات. وتبحث دراسات البساتين في أسباب غياب خط الرؤية غالباً وفي تأثير الغطاء النباتي على فقدان المسار (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

لذلك فكرنا أولاً في المحاصيل التالية كسيناريوهات مرشحة:

• الذرة،
• بنجر السكر،
• الطماطم،
• البطاطس،
• البطيخ،
• الفلفل،
• البصل الجاف،
• العنب،
• التفاح،
• اليوسفي.

هذه ليست قائمة لترتيب الإنتاج العالمي، بل مجموعة سيناريوهات هندسية تجمع احتياجات الحساسات وحساسية الري/EC والقيمة الاقتصادية وصعوبة بيئة RF. أنشأنا لكل محصول أولاً جدولاً للمدى–bit rate لمجموعات SF/BW، ثم جدولاً لـ airtime FUOTA للمجموعات نفسها. هذه تقديرات أولية لتوجيه خطة الاختبار، وليست ضمانات ميدانية.

5. لماذا بستان اليوسفي؟

يشكل بستان اليوسفي اختبار ضغط جيداً بين هذه السيناريوهات:

• الأشجار معمرة وذات أوراق كثيفة،
• قد تشغل الأوراق والأغصان مسار RF خلال جزء كبير من السنة،
• غالباً ما تُثبت العقد قرب الأرض أو الجذع،
• قد توجد عدة صفوف من الأشجار بين البوابة والعقدة،
• يختلف الانتشار على طول الصف عن الانتشار بين الصفوف.

إن وجود دراسات RF في بساتين الحمضيات تدرس موضع العقدة وارتفاع الهوائي وعمق الغطاء النباتي والمسافة معاً يوضح أن موضع الهوائي لا يمكن تفسيره بالمسافة بالأمتار وحدها (citrus orchard RF deployment study). كما سجلت تجارب وضع الحساسات في الحقول الحمضية مستويات مختلفة للإشارة المستقبلة عند اختلاف ارتفاع الهوائيات وغطاء الأشجار (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

لم يعد السؤال الحاسم “كم كيلومتراً تصل LoRa؟”، بل:

هل تستطيع كل عقدة في بستان اليوسفي الاتصال مع link margin كافٍ، وهل يستطيع downlink نفسه إكمال نقل برنامج ثابت طويل؟

6. ارتفاع الهوائي: متر واحد و5 أمتار و50 سنتيمتراً

وضع البوابة على ارتفاع متر واحد

قد يترك عمود بارتفاع يقارب متر واحد الهوائي داخل الطبقة السفلية من الجذوع والأوراق. عندها تدخل صفوف الأشجار والأغصان والأوراق مباشرة في مسار الانتشار. ورؤية الهوائي الآخر لا تعني أن منطقة Fresnel مفتوحة؛ فقد تظل انعكاسات الأرض وصفوف الأشجار هي العامل الغالب.

وضع البوابة على ارتفاع 5 أمتار

يمكن لارتفاع يقارب 5 أمتار أن يقرب هوائي البوابة من قمم كثير من أشجار اليوسفي أو يرفعه فوقها. لا ينشئ ذلك خط رؤية تلقائياً في كل البستان، لكنه قد يقلل العوائق من جانب البوابة وفقدان الأرض وتأثير التيجان على المسار الأفقي. وتظهر قياسات البساتين أن تأثير الأوراق يعتمد على قرب الهوائيات من الأرض أو من قمم الأشجار (orchard foliage path-loss study).

لذلك فعمود 5 أمتار ليس “مضاعف مدى” بحد ذاته. يجب قياس فائدته مع:

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

وضع الهوائيين على ارتفاع 50 سنتيمتراً

تتمثل جاذبية وضع الهوائي على ارتفاع 50 سم في إبقائه تحت الغطاء العلوي واستخدام الممر بين الجذوع. لكن عبارة “لا يمر عبر الأوراق” لا تعني “وجود خط رؤية”. عند هذا الارتفاع:

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

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

7. وصلة التليمترية ليست وصلة FUOTA

قدرة الحساس على إرسال حزمة قياس صغيرة بانتظام لا تعني قدرته على تنزيل برنامج ثابت بحجم 1 MB عبر الشبكة نفسها. التليمترية عادة uplink متباعد، أما FUOTA فهي عملية طويلة يغلب عليها downlink وتتطلب إعادة إرسال الأجزاء المفقودة.

تفتح أجهزة LoRaWAN Class A نافذتي استقبال قصيرتين بعد uplink. أما أجهزة Class C فتبقي المستقبل متاحاً مدة أطول عندما لا ترسل، ولذلك يكون التشغيل المؤقت في Class C مفيداً لنقل downlink كبير (LoRaWAN Specification).

FUOTA ليست أمراً واحداً من نوع “أرسل حزمة البرنامج الثابت”. تفصل لبنات LoRa Alliance المسؤوليات كما يلي:

• TS004 Fragmented Data Block Transport: تجزئة البيانات الكبيرة وإدارة جلسة التجزئة (TS004-2.0.0).
• TS005 Remote Multicast Setup: جدولة multicast مؤقت ونوافذ توزيع Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol: إدارة إصدارات البرنامج الثابت والعتاد وإعادة التشغيل وصور التحديث (TS006-1.0.0).
• TS007 Multi Package Access: الإبلاغ عن حزم الجهاز وFPorts حتى تستخدم عدة أوامر عدداً أقل من downlink (TS007-1.0.0).

يتطلب استخدام هذه المعايير معاً تطويراً إضافياً وتحقق HIL، بصرف النظر عن مدى RF.

8. تكلفة صورة برنامج ثابت كاملة بحجم 1 MB

يمكن حساب الحد الأدنى التقريبي لصورة كاملة بحجم 1 MB هكذا:

عدد البتات المطلوب نقلها / bit rate النظري

عند 1 MB و5.47 kbit/s، يستغرق نقل PHY وحده نحو 25.5 دقيقة. وإذا طبقنا استخداماً للقناة بنسبة 10% باعتباره افتراضاً لسيناريو، يرتفع الحد الأدنى النظري إلى نحو 4.25 ساعات. لا يشمل ذلك ترويسات LoRaWAN وبيانات أجزاء TS004 والتكافؤ/redundancy وفقدان الحزم وإعادة المحاولة وإعداد جلسة Class C. يجب التحقق من القوانين الإقليمية وحدود استخدام القناة للنطاق والبلد (RP002 Regional Parameters).

لذلك قد يكون اختيار إعداد FUOTA بهدف “أطول مدى” فقط هدفاً خاطئاً. الإعداد الأفضل يقلل airtime الكلي مع الحفاظ على link margin موثوق.

9. Delta OTA: نقل الفرق لا البرنامج الثابت كاملاً

في Delta OTA، يرسل الخادم الفرق بين الصورة الأساسية التي يبلغ عنها الجهاز والصورة المستهدفة. ويطبق الجهاز patch لإعادة بناء البرنامج الثابت المستهدف:

البرنامج الثابت الأساسي على الجهاز
        +
delta patch
        ↓
البرنامج الثابت المستهدف
        ↓
التحقق من SHA-256 والتوقيع
        ↓
اختبار تشغيل MCUboot وتأكيد الصحة

مشروع detools مفتوح المصدر مثال على نهج delta في الأنظمة المضمنة؛ فهو يوثق تطبيق patches متسلسلة بأسلوب streaming وincremental apply بلغة C للأجهزة ذات الذاكرة المحدودة (detools README). وفي مشروع Agronode، عُرّف مسار إنشاء وتطبيق delta مع base SHA وtarget SHA وحجم الصورة وتخطيط MCUboot (توثيق Agronode Delta OTA، كود تطبيق delta).

تذكر القياسات الحالية للمشروع أن delta بين الإصدارات المتتابعة يبلغ نحو 15–53 KB مقابل صورة كاملة تبلغ نحو 944 KB (توثيق Delta OTA للمشروع). يخص هذا القياس تلك الإصدارات تحديداً؛ ولا ينبغي توقع النسبة نفسها لكل زوج من الإصدارات.

باستخدام قيمة PHY التقريبية نفسها، 5.47 kbit/s:

هذا ليس زمن FUOTA حقيقياً، بل مقارنة للأحجام. ستضيف التجزئة والتكافؤ وإعادة المحاولات وإدارة الجلسة وقتاً إضافياً.

10. هل يمكن تحديث الأجهزة القديمة جداً بخطوات Delta صغيرة؟

نعم، إذا توفرت سلسلة delta مناسبة:

1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → ... → 1.8.0

كل سهم هو جلسة FUOTA مستقلة وحاجز أمان مستقل. لا ينبغي للخادم بدء patch التالي إلا بعد أن يكون الجهاز قد:

1. أكمل جلسة التجزئة،
2. تحقق من base SHA،
3. أنشأ الصورة المستهدفة وتحقق من target SHA،
4. اجتاز اختبار تشغيل MCUboot،
5. أكد البرنامج الثابت الجديد بفحص صحة،
6. أبلغ عن الإصدار الجديد وهوية الصورة.

يمكن لتدفق test–confirm–revert في MCUboot إعادة الجهاز إلى الصورة العاملة السابقة عند الإقلاع التالي إذا فشلت الصورة الجديدة؛ وهذا نمط أساسي في bootloader لتقليل خطر تعطل الجهاز نهائياً في التحديثات البعيدة (توثيق تصميم MCUboot، توقيع الصور وأدوات MCUboot).

عيب السلسلة متعددة الخطوات هو تكرار إعداد الجلسة وairtime والطاقة وإعادة التشغيل واحتمال الخطأ في كل خطوة. إذا كان احتمال نجاح كل hop مستقلاً ويساوي 98%، فإن احتمال إكمال عشرة hops بلا إعادة محاولة يقارب 0.98^10 = 81.7%. هذا ليس تنبؤاً بالنجاح الميداني، بل نموذج يوضح كيف يضاعف عدد hops المخاطر.

11. النموذج الصحيح هو رسم بياني لـ delta لا قائمة ملفات delta

الاحتفاظ بالإصدارات المتجاورة فقط نموذج بسيط:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

في الإنتاج، من الأفضل الاحتفاظ بالصور الكاملة وأنواع delta المتعددة معاً:

1.0 ──→ 1.1 ──→ 1.2 ──→ 1.3 ──→ 1.4
 │                  │                  ▲
 └──── checkpoint ──┴── direct patch ───┘

سياسة artifact المقترحة:

• الاحتفاظ بصورة كاملة وموقعة لكل release.
• الاحتفاظ بـ delta المتتالية N→N+1 كـ artifacts طويلة الأجل وغير قابلة للتغيير.
• إنشاء delta مباشرة من الإصدارات الأساسية الموجودة فعلياً في الحقل إلى أحدث release.
• الاحتفاظ بـ bridge delta من إصدارات LTS/checkpoint المختارة إلى أحدث release.
• تخزين base SHA وtarget SHA وboard وhardware revision وvariant وpartition geometry مع كل delta.
• عدم حذف الصور الكاملة؛ فهي المصدر canonical لإنشاء delta والتحليل الجنائي والاسترداد.

يوضح script الـ artifact الحالي في Agronode إنشاء delta مباشرة من الإصدارات الأساسية الموجودة في الحقل (ensure_field_deltas.py). تبحث سياسة backend الحالية عن تطابق مباشر بين base وtarget؛ ويلزم أيضاً graph/path planner لتخطيط المسار A→B→C تلقائياً عندما يتوفر A→B وB→C (ota_policy.py).

يمكن للخادم اختيار المسار بدالة التكلفة التالية:

تكلفة المسار =
إجمالي بايتات patch
+ airtime المقدّر
+ تكلفة الجلسة/إعادة التشغيل لكل hop
+ خطر فقدان الحزم والفشل
+ طاقة الجهاز وتكلفة الصيانة

السياسة العملية الأولى هي استخدام patch مباشر إذا كان موجوداً وحجمه معقولاً. وإذا كان كبيراً جداً، تُجرّب route من checkpoint لا يتجاوز 2–3 hops مضبوطة. يجب الاحتفاظ بالصورة الكاملة كمسار للاسترداد أو bootstrap أو النقل البديل، لا كـ “حل أخير” تلقائي عبر LoRa.

12. بوابات الأمان المطلوبة لتشغيل Delta OTA

لا يلغي Delta OTA فحوص الأمان؛ بل يجعل الهوية الدقيقة للصورة الأساسية أكثر أهمية.

يجب التحقق على الأقل من القيم التالية لكل patch:

• base firmware SHA-256 الذي أبلغ عنه الجهاز،
• base SHA-256 الذي يتوقعه patch،
• board وhardware revision،
• partition/slot geometry،
• target firmware SHA-256،
• توقيع MCUboot ومفتاح signing المسموح،
• توافق إصدار البرنامج الثابت المستهدف مع سياسة downgrade.

يتحقق MCUboot من سلامة الصورة وتوقيعها، ويمكنه توفير rollback عندما لا يتم تأكيد test boot بشكل دائم (التوثيق الرسمي لـ MCUboot). ويجب أن يرفض كود تطبيق delta عدم توافق base وlayout قبل إنشاء الصورة المستهدفة (تطبيق Agronode لـ delta).

تحتاج الأجهزة القديمة جداً أيضاً إلى إصدار bootstrap لـ FUOTA. فإذا لم تتضمن البرامج الثابتة السابقة عميلاً للتجزئة أو كود delta-apply أو دعم bootloader المطلوب، فلا يمكن إدخال الجهاز مباشرة في سلسلة delta. يجب تحديثه أولاً عبر BLE أو Wi-Fi أو الشبكة الخلوية أو صورة كاملة مضبوطة.

13. خارطة طريق عملية لهذا المشروع

المرحلة 1 — تثبيت افتراضات RF

• تأكيد الطرازين الدقيقين لـ Dragino وE22.
• اختيار المنطقة وخطة التردد.
• قياس القدرة عند خرج الكابل أو التحقق منها في ورقة البيانات.
• تسجيل كسب الهوائي وفقدان الكابل والاستقطاب.
• قياس سيناريوهات 50 سم ومتر واحد وبوابة على ارتفاع 5 أمتار على المسار نفسه في بستان اليوسفي.

المرحلة 2 — إنشاء خريطة اتصال ميدانية

• تسجيل RSSI وSNR عند كل نقطة قياس.
• قياس معدل نجاح الحزم واعتماد النتيجة على الاتجاه.
• مقارنة الظروف الجافة والمروية والممطرة وكثافات الأوراق المختلفة.
• قياس مسار على طول الصفوف وآخر عبر الصفوف.
• تحديد الحد الأدنى لـ link margin المطلوب لـ FUOTA بشكل منفصل.

المرحلة 3 — إكمال نقل LoRaWAN FUOTA

• تنفيذ جلسة التجزئة TS004.
• تنفيذ دورة حياة Class C/multicast المؤقتة باستخدام TS005.
• ربط إدارة إصدار firmware/reboot في TS006 مع package discovery في TS007.
• اختبار فقدان الأجزاء وإعادة المحاولة والانقطاع وإعادة تشغيل البوابة.
• عدم ضمان نجاح Delta FUOTA من طرف إلى طرف عبر LoRa قبل إكمال هذه المرحلة.

المرحلة 4 — إضافة artifact delta وإدارة المسارات

• تخزين كل release موقعة وكاملة كـ artifact canonical.
• إنشاء delta متجاورة وdelta مباشرة من قواعد الحقل النشطة إلى أحدث release.
• جعل metadata الخاصة بـ delta غير قابلة للتغيير مع base/target SHA وهوية العتاد.
• تنفيذ اختيار patch مباشر ومسار multi-hop محدود على الخادم.
• بعد كل hop، انتظار إشارات الإصدار وSHA وصحة boot وصحة التطبيق.

المرحلة 5 — تعريف مقياس نجاح FUOTA

لا ينبغي أن يعني النجاح فقط “وصلت كل الحزم”. يجب الإبلاغ معاً عن:

• بايتات patch وairtime الكلي،
• معدل فقدان الأجزاء وعدد إعادة المحاولات،
• زمن اكتمال التحديث،
• استهلاك الطاقة،
• معدل نجاح test boot،
• معدل التأكيد الدائم،
• معدل rollback،
• نجاح كل hop والنجاح الكلي عند الحاجة إلى عدة hops.

الخلاصة

مشكلة LoRa في بستان اليوسفي ليست مجرد سؤال “كم كيلومتراً يمكننا تغطيته؟”. يفرض SF وBW مفاضلة بين المدى وbit rate؛ ويغير الغطاء النباتي الوصلة النظرية في ظروف الحقل؛ ويؤثر ارتفاع الهوائي واتجاه الصفوف في النتيجة؛ كما تتطلب FUOTA سعة downlink مختلفة تماماً عن سعة حزم التليمترية الصغيرة.

لهذا لا تصف قيمة Semtech المرجعية البالغة 6 كم ومسافة التحديث الموثوقة في بستان كثيف المقياس نفسه. تجمع البنية الصحيحة بين link budget RF مقاس وارتفاع مناسب للبوابة ونقل FUOTA قياسي وفق TS004/TS005 وبوابات أمان MCUboot ورسم بياني لـ artifacts الخاصة بـ Delta OTA.

عندما يخفض Delta OTA صورة كاملة بحجم 1 MB إلى patches بحجم يقارب 15–53 KB، يمكنه تقليل airtime لـ FUOTA بشكل كبير. لكن خوارزمية delta وحدها لا تحول هذه الميزة إلى منتج موثوق. يجب أن يعرف الخادم base SHA الدقيق للجهاز، وأن يختار مساراً مباشراً أو multi-hop محدوداً، وأن يتحقق من كل hop، وأن يحتفظ بالصورة الكاملة كمصدر للاسترداد.

باختصار، الهدف ليس أطول مدى، بل نظام LoRaWAN قادر على تنفيذ تحديث firmware قابلاً للقياس والتكرار والرجوع عنه في بستان يوسفي.

المصادر

المعايير والوثائق التقنية للمصنعين

1. Semtech — LoRa and LoRaWAN: A Technical Overview
2. Semtech — Understanding LoRa Adaptive Data Rate
3. LoRa Alliance — RP002 Regional Parameters
4. LoRa Alliance — TS004 Fragmented Data Block Transport
5. LoRa Alliance — TS005 Remote Multicast Setup
6. LoRa Alliance — TS006 Firmware Management Protocol
7. LoRa Alliance — TS007 Multi Package Access
8. LoRa Alliance — LoRaWAN Specification v1.0.3
9. MCUboot — official documentation
10. MCUboot — boot design and test/revert flow
11. detools — sequential and incremental delta patching

دراسات انتشار RF الزراعية

12. Influence of foliage on radio path losses for WSN planning in orchards
13. Test of WSN RF signal propagation based on different node deployments in citrus orchards
14. Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling