از مثال ۶ کیلومتری LoRa تا FUOTA قابل‌اعتماد: برد، زمان روی آنتن و Delta OTA در باغ نارنگی

مقادیر برد و زمان‌های FUOTA در این مقاله جایگزین اندازه‌گیری آزمایشگاهی یا میدانی نیستند. پس از مشخص شدن مدل واقعی دستگاه، آنتن، طرح فرکانسی منطقه و شرایط کانال، همه فرض‌ها باید دوباره محاسبه شوند.

خلاصه

در نگاه اول مسئله ساده به نظر می‌رسد: آیا یک گره حسگر مبتنی بر LoRa می‌تواند داده را از باغ نارنگی به گیت‌وی بفرستد؟ وقتی محصول وارد میدان می‌شود، پرسش دشوارتری مطرح می‌شود: چگونه می‌توان صدها کیلوبایت firmware را از همان اتصال، به‌صورت قابل‌اعتماد، منتقل کرد؟

این مطالعه از مثال تقریبی ۶ کیلومتر برای SF9/125 kHz در خلاصه فنی Semtech شروع می‌کند. ابتدا توضیح می‌دهد که چرا این مقدار را نمی‌توان مستقیماً به یک باغ نارنگی متراکم تعمیم داد، سپس بده‌بستان میان برد و نرخ داده را در spreading factor (SF) و bandwidth (BW) بررسی می‌کند. همچنین توضیح می‌دهد که link budget به معنای جمع کردن توان خروجی دو دستگاه نیست؛ فرستنده فعال، حساسیت گیرنده مقابل، بهره آنتن‌ها و تلفات محیطی باید با هم ارزیابی شوند. در ادامه، باغ نارنگی از میان چند محیط کشت انتخاب می‌شود و اثر ارتفاع آنتن بررسی می‌گردد. در پایان، به‌جای تصویر کامل firmware، استفاده از Delta OTA، به‌روزرسانی چندمرحله‌ای و انتخاب مسیر delta در سمت سرور پیشنهاد می‌شود.

نتیجه اصلی روشن است: موفقیت FUOTA فقط به پیدا کردن بیشترین برد وابسته نیست. ظرفیت قابل‌اعتماد downlink، زمان روی آنتن کل، duty cycle، افت بسته، جای‌گذاری گیت‌وی، اعتبارسنجی bootloader و هماهنگی به‌روزرسانی باید هم‌زمان طراحی شوند.

۱. چرا مثال تقریبی ۶ کیلومتری Semtech، برد واقعی در باغ نیست؟

خلاصه فنی LoRa شرکت Semtech برای 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). بنابراین جدول ۶ کیلومتری Semtech می‌تواند فرضیه آغازین برای اندازه‌گیری میدانی باشد، اما نتیجه نهایی نیست.

در نتیجه، پرسش مرکزی تغییر می‌کند:

مرجع ۶ کیلومتری فضای باز Semtech در یک باغ نارنگی متراکم به چه link margin، نرخ موفقیت بسته و زمان روی آنتن FUOTA تبدیل می‌شود؟

۲. SF و BW چگونه برد را تغییر می‌دهند؟

در لایه فیزیکی LoRa، spreading factor تعیین می‌کند داده‌ها تا چه اندازه روی نمادهای chirp گسترده شوند. خلاصه فنی Semtech توضیح می‌دهد که در بازه SF7 تا SF12، افزایش SF حساسیت گیرنده را بهتر می‌کند، اما bit rate و سرعت انتقال داده را کاهش می‌دهد (Semtech, LoRa and LoRaWAN: A Technical Overview).

این رابطه را می‌توان چنین خلاصه کرد:

جدول عددی SF/BW و برد برای باغ نارنگی

جدول زیر یک برآورد مهندسی برای برنامه‌ریزی در باغ مرکباتی با ارتفاع تقریبی ۲٫۵ تا ۴ متر، پوشش برگ متراکم و آبیاری‌شده در تمام سال است. سلول‌ها با قالب برد (m) / نرخ بیت ناخالص PHY (kbit/s) نمایش داده می‌شوند؛ برای طراحی قابل‌اعتماد باید حد پایین بازه را مبنا قرار داد. سناریوی محاسبه E22-900M22S/SX1262، فرکانس 868 MHz، کدینگ CR 4/5، بهره آنتن 0 dBi، افت 2 dB در کابل و کانکتورها، حاشیه اضافی 10 dB برای fading و ایمنی، و آنتنِ خارج از خاک را فرض می‌کند (اطلاعات سازنده E22-900M22S).

نرخ بیت PHY از رابطه R_b = SF × (BW / 2^SF) × 4/5 به دست می‌آید و throughput واقعی برنامه نیست. headerهای LoRaWAN، duty cycle، زمان انتظار، تکرار ارسال، فراداده قطعه‌بندی و افت بسته، سرعت مفید را بیشتر کاهش می‌دهند. بردهای جدول، برآوردهای برنامه‌ریزی بر پایه فرض‌های RF بالا هستند، نه اندازه‌گیری میدانی یا مقادیر تضمین‌شده برای باغ نارنگی. ستون‌های SF5–SF6 و BW250/BW500 برای مقایسه LoRa خام هستند؛ ترکیب‌های خارج از نرخ‌های استاندارد LoRaWAN EU868 باید جداگانه با پارامترهای منطقه‌ای بررسی شوند.

پارامترهای منطقه‌ای LoRaWAN طرح کانال‌ها، data rateهای مجاز، محدودیت‌های توان و قیود منطقه‌ای را تعیین می‌کنند. بنابراین جدول 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 پایین‌تر می‌تواند زمان به‌روزرسانی را کاهش دهد.

۳. Link budget: توان دو دستگاه با هم جمع نمی‌شود

توان خروجی Dragino و E22 را نمی‌توان در یک محاسبه به‌سادگی با هم جمع کرد. هر جهت RF باید جداگانه محاسبه شود:

توان دریافتی =
توان خروجی فرستنده فعال
+ بهره آنتن فرستنده
+ بهره آنتن گیرنده
− تلفات کابل و کانکتور
− تلفات انتشار
− تلفات برگ، تنه، زمین و دیگر عوامل محیطی

در جهت E22 → Dragino، توان خروجی E22 و حساسیت گیرنده Dragino استفاده می‌شود. در جهت Dragino → E22، توان Dragino و حساسیت E22 استفاده می‌شود. برد دوطرفه قابل استفاده را ضعیف‌ترین جهت تعیین می‌کند. چون حساسیت با SF، BW، coding rate و شرایط اندازه‌گیری تغییر می‌کند، یک عدد واحد برای «برد دستگاه» از نظر فنی کامل نیست. خلاصه فنی LoRa از Semtech رابطه میان پارامترهای مدولاسیون LoRa، حساسیت و bit rate را توضیح می‌دهد.

در محاسبات میدانی این مقاله، پیش از مشخص شدن مدل‌های دقیق Dragino و E22، نوع آنتن، توان اندازه‌گیری‌شده در خروجی و مجوزهای منطقه‌ای، مقدار اسمی dBm را فرض نکنید. دیتاشیت جای اندازه‌گیری میدانی را نمی‌گیرد.

۴. چرا نوع کشت را یک مسئله مستقل RF در نظر می‌گیریم؟

یک تنظیم رادیویی یکسان در همه محیط‌های کشاورزی نتیجه یکسانی نمی‌دهد. برگ‌ها، شاخه‌ها، تنه‌ها، رطوبت خاک، هندسه ردیف‌ها و باران می‌توانند بر پراکندگی، جذب و fading چندمسیری اثر بگذارند. مطالعات باغ‌ها بررسی کرده‌اند که چرا خط دید اغلب وجود ندارد و چرا پوشش گیاهی تلفات مسیر را تغییر می‌دهد (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

به همین دلیل ابتدا این کشت‌ها را به‌عنوان سناریوهای نامزد در نظر گرفتیم:

• ذرت،
• چغندر قند،
• گوجه‌فرنگی،
• سیب‌زمینی،
• هندوانه،
• فلفل،
• پیاز خشک،
• انگور،
• سیب،
• نارنگی.

این فهرست رتبه‌بندی تولید جهانی نیست؛ مجموعه‌ای از سناریوهای مهندسی است که نیاز حسگر، حساسیت آبیاری/EC، ارزش اقتصادی و دشواری RF را با هم ترکیب می‌کند. برای هر کشت ابتدا جدول برد–bit rate را برای ترکیب‌های SF/BW ساختیم و سپس برای همان ترکیب‌ها جدول airtime FUOTA را ایجاد کردیم. این جدول‌ها برآوردهای اولیه برای هدایت برنامه آزمون هستند، نه تضمین عملکرد در میدان.

۵. چرا باغ نارنگی؟

باغ نارنگی میان این نامزدها آزمون فشار مناسبی است:

• درختان چندساله و دارای پوشش برگ متراکم‌اند،
• برگ‌ها و شاخه‌ها می‌توانند در بخش بزرگی از سال در مسیر RF قرار بگیرند،
• گره‌ها اغلب نزدیک زمین یا تنه نصب می‌شوند،
• ممکن است چند ردیف درخت میان گیت‌وی و گره قرار داشته باشد،
• انتشار در امتداد یک ردیف با انتشار میان ردیف‌ها یکسان نیست.

وجود مطالعات RF در باغ‌های مرکبات که جای گره، ارتفاع آنتن، عمق پوشش گیاهی و فاصله را هم‌زمان بررسی می‌کنند نشان می‌دهد که جای آنتن را نمی‌توان فقط با فاصله بر حسب متر توضیح داد (citrus orchard RF deployment study). آزمایش‌های جای‌گذاری حسگر در زمین‌های مرکبات نیز با تغییر ارتفاع آنتن و پوشش درختان، سطوح متفاوتی از سیگنال دریافتی را گزارش کرده‌اند (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

پرسش مهم دیگر «LoRa چند کیلومتر می‌رسد؟» نیست، بلکه این است:

آیا هر حسگر در باغ نارنگی با link margin کافی متصل می‌شود و آیا همان downlink می‌تواند یک انتقال طولانی firmware را کامل کند؟

۶. ارتفاع آنتن: یک متر، ۵ متر و ۵۰ سانتی‌متر

قرار دادن گیت‌وی در ارتفاع یک متر

دکل تقریباً یک‌متری ممکن است آنتن را داخل لایه پایینی تنه و برگ قرار دهد. در این حالت ردیف درختان، شاخه‌ها و برگ‌ها مستقیماً وارد مسیر انتشار می‌شوند. دیدن آنتن مقابل به معنای باز بودن ناحیه Fresnel نیست؛ انعکاس زمین و ردیف درختان همچنان می‌توانند غالب باشند.

قرار دادن گیت‌وی در ارتفاع ۵ متر

ارتفاع تقریباً ۵ متری می‌تواند آنتن گیت‌وی را به تاج بسیاری از درختان نارنگی نزدیک یا از آن بالاتر ببرد. این کار در تمام باغ به‌طور خودکار خط دید ایجاد نمی‌کند، اما ممکن است انسداد سمت گیت‌وی، تلفات مربوط به زمین و اثر تاج درختان بر مسیر افقی را کاهش دهد. اندازه‌گیری‌های باغی نشان می‌دهند اثر برگ‌ها به نزدیک بودن آنتن‌ها به زمین یا تاج درختان وابسته است (orchard foliage path-loss study).

بنابراین دکل ۵ متری به‌تنهایی «ضریب افزایش برد» نیست. فایده آن باید همراه با این عوامل اندازه‌گیری شود:

• قرار گرفتن گیت‌وی در لبه باغ، مرکز باغ یا انتهای یک ردیف،
• جهت‌گیری آنتن موازی یا عمود بر ردیف‌ها،
• بهره آنتن و الگوی تشعشع عمودی،
• تلفات کابل کواکسیال و کانکتورها،
• شیب زمین و انعکاس‌های آن.

قرار دادن هر دو آنتن در ارتفاع ۵۰ سانتی‌متر

جذابیت ارتفاع ۵۰ سانتی‌متر این است که آنتن زیر پوشش بالایی برگ قرار می‌گیرد و از راهروی میان تنه‌ها استفاده می‌کند. اما «از میان برگ‌ها عبور نمی‌کند» به معنای «وجود خط دید» نیست. در این ارتفاع:

• تنه‌ها و شاخه‌های پایینی می‌توانند مانع مستقیم باشند،
• انعکاس زمین و تلفات خاک مرطوب ممکن است افزایش یابد،
• لینک میان ردیف‌ها می‌تواند بسیار ضعیف‌تر از لینک در امتداد ردیف باشد.

بنابراین سناریوی ۵۰ سانتی‌متر باید روی همان مسیری اندازه‌گیری شود که سناریوهای یک متر و ۵ متر اندازه‌گیری می‌شوند؛ نباید آن را به‌عنوان بهبود نظری برد در نظر گرفت. در بسیاری از باغ‌ها، یک فرضیه منطقی این است که آنتن حسگر به سمت راهروی ردیف قرار گیرد، آنتن گیت‌وی بالاتر از تاج درختان نصب شود و در صورت نیاز گیت‌وی دوم اضافه گردد. این یک فرضیه طراحی است که از وابستگی به ارتفاع و جهت در مطالعات RF باغ‌ها به دست آمده و باید در میدان اعتبارسنجی شود.

۷. لینک تله‌متری با لینک FUOTA یکی نیست

این‌که یک حسگر بتواند مرتباً بسته اندازه‌گیری کوچکی ارسال کند، به این معنا نیست که بتواند تصویر firmware یک مگابایتی را از همان شبکه دریافت کند. تله‌متری معمولاً uplink کم‌تکراری است؛ FUOTA عملیاتی طولانی و عمدتاً downlink است که به ارسال دوباره قطعات ازدست‌رفته نیاز دارد.

دستگاه‌های LoRaWAN Class A پس از uplink دو پنجره کوتاه دریافت باز می‌کنند. دستگاه‌های Class C وقتی در حال ارسال نیستند، گیرنده را برای مدت طولانی‌تری در دسترس نگه می‌دارند؛ بنابراین استفاده موقت از Class C برای انتقال بزرگ downlink مفید است (LoRaWAN Specification).

FUOTA یک دستور ساده «بسته firmware را بفرست» نیست. اجزای LoRa Alliance مسئولیت‌ها را جدا می‌کنند:

• TS004 Fragmented Data Block Transport: قطعه‌قطعه کردن داده بزرگ و مدیریت نشست fragmentation (TS004-2.0.0).
• TS005 Remote Multicast Setup: برنامه‌ریزی multicast موقت و پنجره‌های توزیع Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol: مدیریت نسخه firmware و سخت‌افزار، reboot و تصویرهای به‌روزرسانی (TS006-1.0.0).
• TS007 Multi Package Access: گزارش بسته‌ها و FPortهای دستگاه تا چند فرمان با downlink کمتر منتقل شوند (TS007-1.0.0).

استفاده هم‌زمان از این استانداردها، مستقل از برد RF، به توسعه بیشتر و اعتبارسنجی HIL نیاز دارد.

۸. هزینه firmware کامل یک مگابایتی

حد پایین تقریبی برای انتقال firmware کامل یک مگابایتی چنین محاسبه می‌شود:

تعداد بیت‌های قابل انتقال / bit rate نظری

در 1 MB و 5.47 kbit/s، فقط انتقال PHY حدود 25.5 دقیقه طول می‌کشد. اگر استفاده ۱۰ درصدی از کانال را به‌عنوان فرض سناریو اعمال کنیم، حد پایین نظری به حدود 4.25 ساعت می‌رسد. headerهای LoRaWAN، metadata قطعات TS004، parity/redundancy، افت بسته، تکرار ارسال و راه‌اندازی نشست Class C در این محاسبه نیامده‌اند. قوانین منطقه‌ای و محدودیت استفاده از کانال باید برای باند و کشور بررسی شوند (RP002 Regional Parameters).

به همین دلیل، انتخاب تنظیم FUOTA فقط بر اساس «بیشترین برد» می‌تواند هدف اشتباهی باشد. تنظیم مناسب، airtime کل را با حفظ link margin قابل‌اعتماد کمینه می‌کند.

۹. Delta OTA: انتقال تفاوت، نه تمام firmware

در Delta OTA، سرور تفاوت میان تصویر پایه‌ای که دستگاه گزارش کرده و تصویر هدف را می‌فرستد. دستگاه patch را اعمال می‌کند تا firmware هدف را بازسازی کند:

firmware پایه روی دستگاه
        +
delta patch
        ↓
firmware هدف
        ↓
اعتبارسنجی SHA-256 و امضا
        ↓
test boot در MCUboot و تأیید سلامت

پروژه متن‌باز detools نمونه‌ای از این رویکرد در سیستم‌های نهفته است؛ این پروژه اعمال streaming وصله‌های ترتیبی و incremental apply در C را برای دستگاه‌های کم‌حافظه مستند می‌کند (detools README). در پروژه Agronode، جریان ساخت و اعمال delta با base SHA، target SHA، اندازه تصویر و layout مربوط به MCUboot تعریف شده است (مستندات Agronode Delta OTA، کد اعمال delta).

اندازه‌گیری‌های فعلی پروژه، deltaهای releaseهای متوالی را در برابر تصویر کامل حدود 944 KB، در بازه تقریبی 15–53 KB گزارش می‌کنند (مستندات Delta OTA پروژه). این اندازه‌گیری مخصوص همان releaseهاست و نباید برای هر جفت نسخه، نسبت یکسانی انتظار داشت.

با همان مقدار تقریبی PHY یعنی 5.47 kbit/s:

این زمان واقعی FUOTA نیست، بلکه مقایسه اندازه‌هاست. fragmentation، parity، تکرار و مدیریت نشست زمان بیشتری اضافه می‌کنند.

۱۰. آیا می‌توان دستگاه‌های بسیار قدیمی را با گام‌های کوچک Delta به‌روزرسانی کرد؟

بله، اگر زنجیره delta مناسبی وجود داشته باشد:

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

هر فلش یک نشست FUOTA و یک دروازه امنیتی جداگانه است. سرور باید patch بعدی را فقط پس از این مراحل آغاز کند:

1. دستگاه نشست fragmentation را کامل کند،
2. base SHA را اعتبارسنجی کند،
3. تصویر هدف را بسازد و target SHA را اعتبارسنجی کند،
4. test boot در MCUboot را با موفقیت پشت سر بگذارد،
5. firmware جدید را با بررسی سلامت تأیید کند،
6. نسخه و هویت تصویر جدید را گزارش دهد.

جریان test–confirm–revert در MCUboot می‌تواند در صورت شکست تصویر جدید، دستگاه را در راه‌اندازی بعدی به تصویر قبلی و سالم برگرداند؛ این الگویی اساسی برای کاهش خطر brick در به‌روزرسانی‌های راه دور است (مستندات طراحی MCUboot، امضای تصویر و ابزارهای MCUboot).

عیب زنجیره چندمرحله‌ای این است که راه‌اندازی نشست، airtime، انرژی، reboot و خطر شکست در هر گام تکرار می‌شوند. اگر احتمال موفقیت مستقل هر hop برابر ۹۸ درصد باشد، احتمال تکمیل ده hop بدون retry تقریباً 0.98^10 = 81.7% است. این پیش‌بینی موفقیت میدانی نیست؛ مدلی است برای نشان دادن اثر تجمعی تعداد hop بر ریسک.

۱۱. مدل درست، گراف delta است نه فهرست فایل‌های delta

نگه‌داری فقط releaseهای مجاور مدل ساده‌ای است:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

در محیط production بهتر است تصویرهای کامل و چند نوع delta با هم نگه‌داری شوند:

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

سیاست پیشنهادی artifact:

• برای هر release یک تصویر کامل و امضاشده نگه‌داری شود.
• deltaهای متوالی N→N+1 به‌عنوان artifactهای تغییرناپذیر و بلندمدت نگه‌داری شوند.
• از نسخه‌های پایه‌ای که واقعاً در میدان وجود دارند، delta مستقیم تا آخرین release ساخته شود.
• deltaهای bridge از نسخه‌های منتخب LTS/checkpoint تا آخرین release نگه‌داری شوند.
• metadata شامل base SHA، target SHA، board، hardware revision، variant و partition geometry همراه هر delta ذخیره شود.
• تصویرهای کامل حذف نشوند؛ آن‌ها منبع canonical برای ساخت delta، بررسی فنی و بازیابی باقی می‌مانند.

در Agronode، اسکریپت artifact موجود ساخت delta مستقیم از نسخه‌های پایه میدانی را نشان می‌دهد (ensure_field_deltas.py). سیاست فعلی backend به دنبال تطبیق مستقیم base–target است؛ برای برنامه‌ریزی خودکار مسیر A→B→C در صورت وجود A→B و B→C، یک graph/path planner نیز لازم است (ota_policy.py).

سرور می‌تواند مسیر را با تابع هزینه زیر انتخاب کند:

هزینه مسیر =
مجموع بایت patchها
+ airtime تخمینی
+ هزینه نشست/reboot به ازای هر hop
+ ریسک افت بسته و شکست
+ انرژی دستگاه و هزینه نگهداری

یک سیاست عملی اولیه این است که اگر patch مستقیم وجود دارد و اندازه‌اش معقول است، از همان استفاده شود. اگر patch مستقیم خیلی بزرگ است، یک مسیر checkpoint با حداکثر 2–3 hop کنترل‌شده امتحان شود. تصویر کامل باید به‌عنوان مسیر بازیابی، bootstrap یا حمل‌ونقل جایگزین نگه‌داری شود، نه «آخرین راه‌حل» خودکار روی LoRa.

۱۲. دروازه‌های امنیتی لازم برای 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 key مجاز،
• سازگاری نسخه firmware هدف با سیاست downgrade.

MCUboot یکپارچگی و امضای تصویر را بررسی می‌کند و اگر test boot به‌طور دائمی تأیید نشود، می‌تواند rollback انجام دهد (مستندات رسمی MCUboot). کد اعمال delta باید پیش از ساخت تصویر هدف، ناسازگاری base و layout را رد کند (اعمال delta در Agronode).

برای دستگاه‌های بسیار قدیمی، تعریف یک نسخه bootstrap برای FUOTA نیز لازم است. اگر firmware قبل از آن نسخه، fragmentation client، کد delta-apply یا پشتیبانی لازم bootloader را نداشته باشد، دستگاه نمی‌تواند مستقیماً وارد زنجیره delta شود. ابتدا باید از طریق BLE، Wi-Fi، شبکه سلولی یا یک تصویر کامل و کنترل‌شده bootstrap شود.

۱۳. نقشه راه عملی برای این پروژه

مرحله ۱ — تثبیت فرض‌های RF

• مدل دقیق Dragino و E22 را مشخص کنید.
• منطقه و طرح فرکانسی را انتخاب کنید.
• توان خروجی واقعی را اندازه بگیرید یا از دیتاشیت تأیید کنید.
• بهره آنتن، تلفات کابل و قطبش را ثبت کنید.
• سناریوهای ۵۰ سانتی‌متر، یک متر و گیت‌وی ۵ متری را در باغ نارنگی روی یک مسیر یکسان اندازه بگیرید.

مرحله ۲ — ساخت نقشه اتصال میدانی

• RSSI و SNR را در هر نقطه اندازه‌گیری ثبت کنید.
• نرخ موفقیت بسته و وابستگی به جهت را اندازه بگیرید.
• شرایط خشک، آبیاری‌شده، بارانی و تراکم‌های مختلف برگ را مقایسه کنید.
• یک مسیر در امتداد ردیف‌ها و مسیر دیگری عمود بر ردیف‌ها اندازه‌گیری کنید.
• حداقل link margin مورد نیاز FUOTA را جداگانه تعیین کنید.

مرحله ۳ — تکمیل حمل‌ونقل LoRaWAN FUOTA

• نشست fragmentation مربوط به TS004 را پیاده‌سازی کنید.
• چرخه عمر موقت Class C/multicast را با TS005 پیاده‌سازی کنید.
• مدیریت firmware version/reboot در TS006 و package discovery در TS007 را متصل کنید.
• افت fragment، retry، قطع انتقال و راه‌اندازی دوباره گیت‌وی را آزمون کنید.
• پیش از تکمیل این مرحله، موفقیت end-to-end Delta FUOTA روی LoRa را تضمین نکنید.

مرحله ۴ — افزودن artifact delta و مدیریت مسیر

• هر release کامل و امضاشده را به‌عنوان artifact canonical ذخیره کنید.
• deltaهای مجاور و deltaهای مستقیم از baseهای فعال میدان تا آخرین release را بسازید.
• metadata delta را با base/target SHA و هویت سخت‌افزار تغییرناپذیر کنید.
• انتخاب patch مستقیم و مسیر multi-hop محدود را در سرور پیاده‌سازی کنید.
• پس از هر hop منتظر سیگنال‌های version، SHA، سلامت boot و سلامت برنامه بمانید.

مرحله ۵ — تعریف معیار موفقیت FUOTA

موفقیت نباید فقط به معنای «همه بسته‌ها رسیدند» باشد. این معیارها باید با هم گزارش شوند:

• بایت patch و airtime کل،
• نرخ افت fragment و تعداد retry،
• زمان تکمیل به‌روزرسانی،
• مصرف انرژی،
• نرخ موفقیت test boot،
• نرخ تأیید دائمی،
• نرخ rollback،
• موفقیت هر hop و موفقیت کلی در صورت نیاز به چند hop.

نتیجه‌گیری

مسئله LoRa در باغ نارنگی فقط این نیست که «چند کیلومتر را می‌توانیم پوشش دهیم؟». SF و BW میان برد و bit rate بده‌بستان ایجاد می‌کنند؛ پوشش گیاهی لینک نظری را در شرایط میدان تغییر می‌دهد؛ ارتفاع آنتن و جهت ردیف‌ها بر نتیجه اثر می‌گذارند؛ و FUOTA به ظرفیت downlink بسیار متفاوتی از بسته‌های کوچک تله‌متری نیاز دارد.

به همین دلیل، مرجع ۶ کیلومتری Semtech و فاصله به‌روزرسانی قابل‌اعتماد در یک باغ متراکم، یک معیار واحد نیستند. معماری درست، link budget اندازه‌گیری‌شده RF، ارتفاع مناسب گیت‌وی، حمل‌ونقل استاندارد FUOTA بر پایه TS004/TS005، دروازه‌های امنیتی MCUboot و گراف artifactهای Delta OTA را با هم ترکیب می‌کند.

وقتی Delta OTA تصویر کامل یک مگابایتی را به patchهایی حدود 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