معمارية OTA الآمنة للأجهزة الصناعية: تحديث ESP32 مع التحقق والاسترجاع

مقدمة: التحديث عن بعد ليس رفع ملف فقط

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

في هذه الحالة يصبح تحديث البرنامج الثابت Firmware وظيفة تشغيلية حرجة، وليس ميزة إضافية.

أي انقطاع أثناء الكتابة قد يترك الجهاز في حالة Brick، وأي ملف غير موثوق قد يفتح بابًا أمنيًا، وأي تحديث غير متوافق مع البيانات المخزنة قد يؤدي إلى توقف الإنتاج.

لذلك صممت معمارية OTA باعتبارها سلسلة ثقة كاملة:

1. اكتشاف إصدار جديد.
2. تنزيل الملف على دفعات.
3. استكمال النقل بعد الانقطاع.
4. التحقق من الحجم والهاش والتوقيع.
5. الكتابة إلى قسم غير نشط.
6. الإقلاع التجريبي.
7. اعتماد الإصدار أو تنفيذ Rollback.
8. تسجيل النتيجة وإبلاغ الخادم.

1. متطلبات النظام

قبل اختيار مكتبة OTA، يجب تعريف القيود.

نسأل أولًا:

• كم حجم Flash المتاح؟
• هل توجد مساحة لقسمين من التطبيق؟
• ما سرعة الشبكة في الموقع؟
• ماذا يحدث عند انقطاع الطاقة؟
• هل الجهاز يعمل 24/7؟
• هل التحديث يجب أن يكون مشفرًا؟
• من يملك صلاحية نشر Firmware؟
• هل الإصدار الجديد متوافق مع مخطط البيانات؟
• ما الحد الأقصى المقبول للتوقف؟

الإجابة عن هذه الأسئلة تحدد partition table والبروتوكول وسياسة الاسترجاع.

2. لماذا Dual-Bank؟

في تصميم A/B أو Dual-Bank يوجد قسمان للتطبيق على الأقل.

+------------------+
| Bootloader       |
+------------------+
| OTA Metadata     |
+------------------+
| App A            |  running
+------------------+
| App B            |  download target
+------------------+
| Filesystem       |
+------------------+

إذا كان App A يعمل، نكتب الإصدار الجديد في App B. لا نلمس البرنامج العامل أثناء التنزيل.

بعد اكتمال التحقق، يغير bootloader مؤشر الإقلاع إلى App B. إذا فشل App B في الاختبار الأول، يعود الجهاز إلى App A.

هذه البنية تقلل خطر تلف البرنامج بسبب انقطاع الطاقة، لكنها تحتاج مساحة Flash أكبر.

3. حالات التحديث

استخدم آلة حالات واضحة بدل مجموعة أعلام مبعثرة.

typedef enum {
    OTA_IDLE,
    OTA_CHECKING,
    OTA_DOWNLOADING,
    OTA_VERIFYING,
    OTA_PENDING_REBOOT,
    OTA_TRIAL_BOOT,
    OTA_CONFIRMED,
    OTA_ROLLBACK,
    OTA_FAILED
} ota_state_t;

لكل حالة انتقالات محددة وأسباب فشل مسجلة.

مثلًا، لا تنتقل من OTA_DOWNLOADING إلى OTA_PENDING_REBOOT إلا بعد تحقق الحجم والهاش والتوقيع.

ولا تنتقل إلى OTA_CONFIRMED إلا بعد تشغيل الخدمات الضرورية ومرور اختبار الصحة.

4. اكتشاف الإصدار

يمكن للجهاز الاستعلام عن manifest عبر HTTPS.

مثال مبسط:

{
  "product": "kts200-controller",
  "version": "2.4.1",
  "min_bootloader": "1.3.0",
  "size": 786432,
  "sha256": "...",
  "signature": "...",
  "url": "https://updates.example.com/kts200-2.4.1.bin"
}

لا تثق في version وحده. يجب التحقق من المنتج والطراز والـ hardware revision.

جهاز Rev A قد لا يملك نفس تعريفات GPIO الموجودة في Rev B.

يجب كذلك منع downgrade غير المصرح به إذا كانت النسخة القديمة تحتوي ثغرة أمنية.

5. HTTPS ليس بديلًا عن التوقيع

يحمي HTTPS النقل بين الجهاز والخادم، لكنه لا يثبت وحده أن الملف صدر من فريقك إذا تعرض الخادم أو حساب النشر للاختراق.

يجب توقيع Firmware بمفتاح خاص خارج الجهاز، والتحقق من التوقيع بمفتاح عام مضمّن أو محفوظ في منطقة محمية.

Firmware bytes -> SHA-256 -> digital signature
                                      |
                             public-key verification

المفتاح الخاص لا يوضع في المستودع ولا في جهاز المطور ولا داخل CI logs.

إذا انكشف المفتاح الخاص، نحتاج إلى خطة تدوير مفاتيح وإبطال الإصدارات.

6. التحقق من SHA-256

الهاش يكشف التلف أو التغيير في الملف.

sha256_init(&context);

while (download_has_data()) {
    size_t received = download_chunk(buffer, sizeof(buffer));
    sha256_update(&context, buffer, received);
    flash_write(target_offset, buffer, received);
    target_offset += received;
}

sha256_final(&context, digest);

لا يكفي مقارنة أول بضعة بايتات أو حجم الملف.

يجب مقارنة digest كاملًا مع القيمة الموجودة في manifest الموثوق.

إذا فشل التحقق، لا تجعل القسم الجديد قابلاً للإقلاع.

7. تقسيم التنزيل إلى Chunks

التنزيل دفعة واحدة يستهلك RAM ويصعب استئنافه.

الأفضل استخدام chunks بحجم يناسب TCP وFlash، مثل 4 أو 16 كيلوبايت حسب المنصة.

كل دفعة تحتاج:

• offset.
• length.
• رقم تسلسلي.
• checksum اختياري.
• مهلة.
• عدد محاولات.

عند انقطاع الشبكة، يقرأ الجهاز آخر offset مؤكد ويكمل من هناك.

لكن الاستئناف الآمن يتطلب أن يكون الخادم قادرًا على خدمة HTTP Range أو بروتوكول مكافئ.

8. الكتابة إلى Flash

Flash لا يتعامل مثل RAM.

غالبًا نحتاج إلى مسح sector كامل قبل إعادة الكتابة، ولا يمكن تحويل البت من 0 إلى 1 دون erase.

لذلك يجب:

1. التأكد من أن العنوان محاذٍ للحد المطلوب.
2. مسح القطاعات المستهدفة فقط.
3. الكتابة على دفعات مناسبة.
4. التحقق من القراءة بعد الكتابة عند الحاجة.
5. عدم قطع الطاقة أثناء تحديث metadata الحساسة.

لا تسجل عدادًا في نفس القطاع آلاف المرات دون wear leveling.

9. حماية البيانات المحلية

Firmware وبيانات الجهاز شيئان مختلفان.

معالجة التحديث يجب ألا تمس calibration أو counters أو سجلات الأعطال دون خطة ترحيل.

أضف رقم إصدار لمخطط البيانات:

typedef struct {
    uint32_t magic;
    uint16_t schema_version;
    uint16_t payload_length;
    uint32_t crc32;
} settings_header_t;

عند الإقلاع، يقرأ الإصدار الجديد المخطط القديم ويجري migration مرة واحدة.

إذا فشل migration، يجب استخدام نسخة احتياطية أو القيم الافتراضية الآمنة.

10. Bootloader وسجل الإقلاع

يحتاج bootloader إلى metadata مقاومة للانقطاع.

مثال منطقي:

typedef struct {
    uint32_t magic;
    uint8_t active_slot;
    uint8_t pending_slot;
    uint8_t boot_attempts;
    uint8_t confirmed;
    uint32_t metadata_crc;
} boot_record_t;

لا تكتب السجل بطريقة قد تتركه نصف محدث.

استخدم نسختين من السجل أو journal صغيرًا مع sequence number وCRC.

عند الإقلاع، يختار bootloader أحدث سجل صالح.

11. Trial Boot

بعد تثبيت الإصدار الجديد، لا نعلنه مستقرًا فورًا.

يبدأ الجهاز في وضع trial مع عدد محاولات محدود.

خلال هذه المرحلة يتحقق التطبيق من:

• تشغيل scheduler.
• توفر الذاكرة الأساسية.
• قراءة إعدادات صحيحة.
• الاتصال بالحساسات الحرجة.
• سلامة watchdog.
• نجاح self-test.
• قدرة الجهاز على إرسال heartbeat.

إذا مر كل شيء، يستدعي التطبيق دالة اعتماد الإصدار.

إذا أعيد التشغيل قبل الاعتماد، يزيد bootloader عداد المحاولات.

بعد تجاوز الحد، يعود إلى القسم السابق.

12. Watchdog وRollback

Watchdog ليس مجرد مؤقت لإعادة التشغيل؛ في OTA هو جزء من سياسة الاسترجاع.

إذا علق التطبيق الجديد قبل إعلان نجاحه، يعيد watchdog تشغيل الجهاز.

عند الإقلاع التالي يرى bootloader أن النسخة pending ولم تؤكد، فيختار النسخة المستقرة السابقة.

يجب منع حلقة rollback لا نهائية عبر عداد ومحاولة واضحة.

سجل سبب الاسترجاع:

• crash.
• watchdog timeout.
• failed self-test.
• invalid signature.
• missing configuration.
• network confirmation timeout.

13. التشفير والهوية

هناك فرق بين تشفير الاتصال وتشفير Firmware.

HTTPS يحمي المسار، أما تشفير الملف نفسه فيحمي السرية عند تخزينه أو نسخه.

ليس كل Firmware يحتاج سرية، لكنه يحتاج أصالة وسلامة غالبًا.

إذا كان الملف مشفرًا، يجب إدارة مفتاح فك التشفير داخل الجهاز بعناية، وعدم وضعه في manifest مكشوف.

كما يجب أن يملك كل جهاز هوية فريدة وشهادة أو token قابلًا للإبطال.

14. أقل صلاحيات للخادم

خادم التحديث لا ينبغي أن يملك صلاحية تعديل قواعد البيانات كلها.

قسّم النظام إلى:

• خدمة بناء وتوقيع.
• مخزن ملفات read-only بعد النشر.
• API لإصدار manifest.
• خدمة telemetry.
• لوحة صلاحيات للمراجعة.

سجل من نشر النسخة ومتى ولأي مجموعة أجهزة.

التحديث التدريجي أفضل من إرسال Firmware إلى كل الأجهزة دفعة واحدة.

15. Canary وStaged Rollout

ابدأ بنسبة صغيرة من الأجهزة.

راقب crash rate وrollback rate ووقت الإقلاع واستهلاك الذاكرة.

إذا تجاوزت المؤشرات الحدود المسموحة، أوقف النشر تلقائيًا.

مثال لخطة:

1%   لمدة ساعتين
10%  لمدة ست ساعات
30%  لمدة يوم
100% بعد اعتماد النتائج

يجب أن تكون المجموعة الأولى ممثلة للمواقع والشبكات والأجهزة المختلفة، لا مجرد أول عشرة أجهزة متصلة.

16. تحديث BLE وWeb Serial

في بعض البيئات لا يتوفر الإنترنت، لذلك قد تحتاج إلى قناة محلية.

BLE مناسب للإعداد الأولي أو ملف صغير، لكن سرعة النقل والطاقة والمدى محدودة.

Web Serial يسمح لفني متصل عبر USB أو محول مناسب بنقل Firmware من المتصفح.

يجب أن يتطلب التحديث المحلي إثبات صلاحية الملف، لا أن يتجاوز التوقيع لأنه محلي.

المستخدم المحلي قد يملك وصولًا فيزيائيًا، لكنه ليس بالضرورة جهة موثوقة.

17. التعامل مع انقطاع الطاقة

اختبر انقطاع الطاقة في كل مرحلة:

• أثناء erase.
• أثناء كتابة chunk.
• بعد آخر chunk وقبل الهاش.
• بعد الهاش وقبل تغيير boot flag.
• أثناء trial boot.
• أثناء migration للبيانات.

كل حالة يجب أن تنتهي إما باستكمال آمن أو عودة إلى نسخة صالحة.

لا تكتب active slot قبل اكتمال كل عمليات التحقق.

18. اختبارات الأمان

اختبر رفض:

• ملف بتوقيع خاطئ.
• ملف معدل بعد التوقيع.
• منتج غير مطابق.
• إصدار أقل من minimum version.
• ملف أكبر من القسم.
• manifest ناقص.
• شهادة منتهية.
• خادم غير موثوق.
• إعادة إرسال قديمة Replay.

يجب أيضًا اختبار امتلاء Flash وفشل DNS وانتهاء المهلة وتذبذب الطاقة.

19. اختبارات التوافق

احتفظ بمصفوفة توافق بين:

لا تعتمد على رقم الإصدار النصي وحده. قارن major وminor وhardware revision وسياسة الترحيل.

20. المراقبة بعد النشر

أرسل telemetry صغيرة وآمنة:

• إصدار bootloader.
• إصدار Firmware.
• القسم النشط.
• آخر سبب إقلاع.
• عدد محاولات trial.
• آخر نتيجة self-test.
• إصدار schema.
• وقت آخر heartbeat.

لا ترسل أسرارًا أو بيانات شخصية ضمن سجلات التحديث.

21. أخطاء شائعة

الكتابة إلى القسم العامل

قد تنجح في المختبر، لكنها تفشل عند انقطاع الطاقة.

الثقة في اسم الملف

اسم firmware-final.bin لا يثبت شيئًا. التوقيع هو المرجع.

عدم اختبار Rollback

الميزة غير المختبرة ليست خطة استرجاع.

خلط Firmware بالبيانات

مسح قسم واحد دون تصميم قد يحذف calibration أو هوية الجهاز.

عدم وجود حد للمحاولات

قد يدخل الجهاز في reboot loop ويستنزف البطارية.

نشر شامل بلا Canary

خطأ واحد قد يعطل أسطولًا كاملًا.

22. نموذج تدفق كامل

Device -> fetch manifest
Device -> verify product and version
Device -> download chunks to inactive slot
Device -> calculate SHA-256
Device -> verify signature
Device -> mark slot pending
Device -> reboot
Bootloader -> start trial slot
Firmware -> run self-test
Firmware -> confirm slot
Device -> report success

إذا فشل أي شرط قبل إعادة التشغيل، يبقى القسم القديم فعالًا.

إذا فشل التطبيق بعد الإقلاع، يتدخل bootloader في الإقلاع التالي.

23. الخلاصة

OTA الآمن هو نظام حياة كامل للبرنامج، وليس endpoint لتحميل ملف.

المعمارية الجيدة تفصل بين التنزيل والتحقق والكتابة والإقلاع والاعتماد.

Dual-Bank يحمي النسخة العاملة، والتوقيع يثبت المصدر، وSHA-256 يكشف التلف، وwatchdog يدعم الاسترجاع، وCanary يقلل أثر الخطأ.

عند اختبار انقطاع الطاقة والملفات الخبيثة وتوافق البيانات والنشر التدريجي، يصبح تحديث الجهاز خدمة يمكن الوثوق بها حتى في المواقع الصناعية البعيدة.

Giriş: OTA yalnızca dosya yüklemek değildir

Cihaz geliştirme laboratuvarındayken programlayıcı bağlanıp hatayı dakikalar içinde düzeltmek mümkündür. Ancak endüstriyel cihaz bir binanın çatısında, bir makinenin içinde veya kolay erişilemeyen bir yerde olabilir.

Bu durumda Firmware güncellemesi ek bir özellik değil, kritik bir işletim işlevidir.

Yazma sırasında kesinti cihazı Brick durumuna bırakabilir, güvenilmeyen dosya güvenlik açığı oluşturabilir ve kayıtlı verilerle uyumsuz bir güncelleme üretimi durdurabilir.

Bu nedenle OTA mimarisi tam bir güven zinciri olarak tasarlanır:

1. Yeni sürümü keşfetmek.
2. Dosyayı parçalar halinde indirmek.
3. Kesintiden sonra aktarımı sürdürmek.
4. Boyut, hash ve imzayı doğrulamak.
5. Etkin olmayan bölüme yazmak.
6. Deneme açılışı yapmak.
7. Sürümü onaylamak veya rollback uygulamak.
8. Sonucu kaydedip sunucuya bildirmek.

1. Sistem gereksinimleri

OTA kütüphanesi seçmeden önce kısıtlar tanımlanmalıdır.

Önce şu sorular sorulur:

• Ne kadar Flash kullanılabilir?
• İki uygulama bölümü için yer var mı?
• Sahadaki ağ hızı nedir?
• Güç kesilirse ne olur?
• Cihaz 24/7 mi çalışır?
• Güncelleme şifreli olmalı mı?
• Firmware yayınlama yetkisi kimde?
• Yeni sürüm veri şemasıyla uyumlu mu?
• Kabul edilebilir en uzun kesinti nedir?

Bu yanıtlar partition table'ı, protokolü ve kurtarma politikasını belirler.

2. Neden Dual-Bank?

A/B veya Dual-Bank tasarımında en az iki uygulama bölümü bulunur.

+------------------+
| Bootloader       |
+------------------+
| OTA Metadata     |
+------------------+
| App A            |  running
+------------------+
| App B            |  download target
+------------------+
| Filesystem       |
+------------------+

App A çalışıyorsa yeni sürüm App B'ye yazılır. İndirme sırasında çalışan programa dokunulmaz.

Doğrulama tamamlandıktan sonra bootloader açılış göstergesini App B'ye çevirir. App B ilk testte başarısız olursa cihaz App A'ya döner.

Bu yapı güç kesintisinin programı bozma riskini azaltır, ancak daha fazla Flash alanı ister.

3. Güncelleme durumları

Dağınık flag'ler yerine açık bir durum makinesi kullanın.

typedef enum {
    OTA_IDLE,
    OTA_CHECKING,
    OTA_DOWNLOADING,
    OTA_VERIFYING,
    OTA_PENDING_REBOOT,
    OTA_TRIAL_BOOT,
    OTA_CONFIRMED,
    OTA_ROLLBACK,
    OTA_FAILED
} ota_state_t;

Her durumun belirli geçişleri ve kaydedilmiş hata nedenleri olmalıdır.

Örneğin boyut, hash ve imza doğrulanmadan OTA_DOWNLOADING durumundan OTA_PENDING_REBOOT durumuna geçilmemelidir.

Gerekli servisler çalışıp sağlık testi geçilmeden OTA_CONFIRMED durumuna geçilmemelidir.

4. Sürümü keşfetmek

Cihaz HTTPS üzerinden bir manifest sorgulayabilir.

{
  "product": "kts200-controller",
  "version": "2.4.1",
  "min_bootloader": "1.3.0",
  "size": 786432,
  "sha256": "...",
  "signature": "...",
  "url": "https://updates.example.com/kts200-2.4.1.bin"
}

Yalnızca version değerine güvenmeyin. Ürün, model ve hardware revision doğrulanmalıdır.

Rev A cihazı Rev B'deki GPIO tanımlarına sahip olmayabilir.

Eski sürümde güvenlik açığı varsa yetkisiz downgrade de engellenmelidir.

5. HTTPS imzanın alternatifi değildir

HTTPS cihaz ile sunucu arasındaki aktarımı korur, ancak sunucu veya yayın hesabı ele geçirilirse dosyanın ekibinizden geldiğini tek başına kanıtlamaz.

Firmware cihaz dışında tutulan özel anahtarla imzalanmalı, imza gömülü veya korumalı bir bölgede tutulan açık anahtarla doğrulanmalıdır.

Firmware bytes -> SHA-256 -> digital signature
                                      |
                             public-key verification

Özel anahtar depoya, geliştirici cihazına veya CI log'larına konulmaz.

Özel anahtar açığa çıkarsa anahtar döndürme ve sürümleri iptal etme planı gerekir.

6. SHA-256 doğrulaması

Hash dosyadaki bozulmayı veya değişikliği ortaya çıkarır.

sha256_init(&context);

while (download_has_data()) {
    size_t received = download_chunk(buffer, sizeof(buffer));
    sha256_update(&context, buffer, received);
    flash_write(target_offset, buffer, received);
    target_offset += received;
}

sha256_final(&context, digest);

İlk birkaç byte'ı veya yalnızca dosya boyutunu karşılaştırmak yeterli değildir.

Tamamlanan digest, güvenilir manifestteki değerle karşılaştırılmalıdır.

Doğrulama başarısızsa yeni bölüm açılışa uygun hale getirilmemelidir.

7. İndirmeyi Chunks olarak bölmek

Tek seferde indirmek RAM tüketir ve devam etmeyi zorlaştırır.

Platforma göre TCP ve Flash'a uyan, örneğin 4 veya 16 kilobyte büyüklüğünde chunk'lar kullanmak daha iyidir.

Her parçada offset, length, sıra numarası, isteğe bağlı checksum, timeout ve deneme sayısı bulunmalıdır.

Ağ kesilince cihaz son onaylı offset'i okur ve oradan devam eder.

Güvenli devam için sunucunun HTTP Range veya eşdeğer bir protokolü desteklemesi gerekir.

8. Flash'a yazmak

Flash RAM gibi davranmaz.

Genellikle yeniden yazmadan önce tüm sector silinmelidir; erase olmadan bit 0'dan 1'e çevrilemez.

1. Adresin gerekli sınıra hizalandığını doğrulayın.
2. Yalnızca hedef sektörleri silin.
3. Uygun büyüklükte parçalar yazın.
4. Gerektiğinde yazma sonrası okumayı doğrulayın.
5. Hassas metadata güncellenirken gücün kesilmemesini sağlayın.

Wear leveling olmadan aynı sektöre binlerce kez sayaç yazmayın.

9. Yerel veriyi korumak

Firmware ve cihaz verisi farklı şeylerdir.

Güncelleme işlemi calibration, sayaçlar veya hata kayıtlarına bir migration planı olmadan dokunmamalıdır.

typedef struct {
    uint32_t magic;
    uint16_t schema_version;
    uint16_t payload_length;
    uint32_t crc32;
} settings_header_t;

Açılışta yeni sürüm eski şemayı okur ve migration'ı bir kez yapar.

Migration başarısız olursa yedek veya güvenli varsayılan değerler kullanılmalıdır.

10. Bootloader ve açılış kaydı

Bootloader kesintiye dayanıklı metadata'ya ihtiyaç duyar.

typedef struct {
    uint32_t magic;
    uint8_t active_slot;
    uint8_t pending_slot;
    uint8_t boot_attempts;
    uint8_t confirmed;
    uint32_t metadata_crc;
} boot_record_t;

Kayıt yarım güncellenmiş halde kalabilecek biçimde yazılmamalıdır.

Sequence number ve CRC içeren iki kayıt kopyası veya küçük bir journal kullanın.

Bootloader açılışta en yeni geçerli kaydı seçer.

11. Trial Boot

Yeni sürüm kurulduktan sonra hemen kararlı ilan edilmez.

Cihaz sınırlı deneme sayısıyla trial modunda başlar.

Bu aşamada uygulama scheduler'ın çalışmasını, temel belleği, doğru ayarları, kritik sensör bağlantılarını, watchdog güvenliğini, self-test'i ve heartbeat gönderebildiğini kontrol eder.

Her şey geçerse uygulama sürümü onaylayan işlevi çağırır.

Onaydan önce yeniden başlarsa bootloader deneme sayacını artırır ve sınır aşılınca önceki bölüme döner.

12. Watchdog ve Rollback

Watchdog yalnızca yeniden başlatma zamanlayıcısı değildir; OTA'da kurtarma politikasının parçasıdır.

Yeni uygulama başarı bildirmeden kilitlenirse watchdog cihazı yeniden başlatır.

Sonraki açılışta bootloader sürümün pending olduğunu ve onaylanmadığını görerek önceki kararlı sürümü seçer.

Bir rollback döngüsünü sayaçla sınırlayın ve nedeni kaydedin: crash, watchdog timeout, failed self-test, invalid signature, missing configuration veya network confirmation timeout.

13. Şifreleme ve kimlik

Bağlantıyı şifrelemek ile Firmware'i şifrelemek farklıdır.

HTTPS yolu korur; dosyanın kendisini şifrelemek depolama veya kopyalama sırasında gizliliği korur.

Her Firmware gizlilik gerektirmez, ancak çoğu zaman özgünlük ve bütünlük gerektirir.

Dosya şifreliyse çözme anahtarı cihaz içinde dikkatle yönetilmeli ve açık manifestte bulunmamalıdır.

Her cihazın iptal edilebilir bir token veya sertifikayla benzersiz kimliği olmalıdır.

14. Sunucuda en az yetki

Güncelleme sunucusu tüm veritabanlarını değiştirme yetkisine sahip olmamalıdır.

• Build ve imzalama servisi.
• Yayın sonrası read-only dosya deposu.
• Manifest yayınlama API'si.
• Telemetry servisi.
• İnceleme yetkileri paneli.

Sürümü kimin, ne zaman ve hangi cihaz grubuna yayınladığını kaydedin.

Aşamalı güncelleme Firmware'i tüm cihazlara tek seferde göndermekten daha iyidir.

15. Canary ve Staged Rollout

Küçük bir cihaz yüzdesiyle başlayın.

Crash rate, rollback rate, açılış süresi ve bellek tüketimini izleyin.

Göstergeler izin verilen sınırı aşarsa yayını otomatik durdurun.

1%   iki saat
10%  altı saat
30%  bir gün
100% sonuçlar onaylandıktan sonra

İlk grup farklı sahaları, ağları ve cihazları temsil etmeli; yalnızca ilk bağlanan on cihaz olmamalıdır.

16. BLE ve Web Serial güncellemesi

İnternet olmayan ortamlarda yerel kanal gerekebilir.

BLE ilk kurulum veya küçük dosya için uygundur, ancak aktarım hızı, enerji ve menzil sınırlıdır.

Web Serial, USB veya uygun bir adaptörle bağlı teknisyenin tarayıcıdan Firmware aktarmasına izin verir.

Yerel güncelleme de dosyanın geçerliliğini kanıtlamalıdır; imza yerel olduğu için atlanmamalıdır.

Yerel kullanıcı fiziksel erişime sahip olabilir, ancak mutlaka güvenilir taraf değildir.

17. Güç kesintisiyle başa çıkmak

Her aşamada güç kesintisini test edin: erase sırasında, chunk yazarken, son chunk'tan sonra hash'ten önce, hash'ten sonra boot flag değiştirilmeden önce, trial boot sırasında ve veri migration'ı sırasında.

Her durum güvenli devamla veya geçerli bir sürüme dönüşle sonuçlanmalıdır.

Tüm doğrulamalar tamamlanmadan active slot yazılmamalıdır.

18. Güvenlik testleri

Şunların reddedildiğini test edin:

• Hatalı imzalı dosya.
• İmzadan sonra değiştirilmiş dosya.
• Uyumsuz ürün.
• Minimum sürümden düşük sürüm.
• Bölümden büyük dosya.
• Eksik manifest.
• Süresi dolmuş sertifika.
• Güvenilmeyen sunucu.
• Eski Replay aktarımı.

Flash doluluğu, DNS hatası, timeout, güç dalgalanması ve ağın kesilmesi de test edilmelidir.

19. Uyumluluk testleri

Yalnızca metin sürümüne güvenmeyin; major, minor, hardware revision ve migration politikasını karşılaştırın.

20. Yayından sonra izleme

Güvenli ve küçük telemetry gönderin: bootloader sürümü, Firmware sürümü, etkin bölüm, son açılış nedeni, trial deneme sayısı, son self-test sonucu, schema sürümü ve son heartbeat zamanı.

Güncelleme kayıtlarına sır veya kişisel veri koymayın.

21. Yaygın hatalar

• Çalışan bölüme yazmak: Laboratuvarda başarılı olsa da güç kesilince başarısız olur.
• Dosya adına güvenmek: firmware-final.bin hiçbir şeyi kanıtlamaz; referans imzadır.
• Rollback'i test etmemek: Test edilmemiş özellik kurtarma planı değildir.
• Firmware ile veriyi karıştırmak: Tasarımsız silme calibration veya cihaz kimliğini yok edebilir.
• Deneme sınırı koymamak: Cihaz reboot loop'a girip pili tüketebilir.
• Canary olmadan herkese yayınlamak: Tek hata bütün filoyu durdurabilir.

22. Tam akış modeli

Device -> fetch manifest
Device -> verify product and version
Device -> download chunks to inactive slot
Device -> calculate SHA-256
Device -> verify signature
Device -> mark slot pending
Device -> reboot
Bootloader -> start trial slot
Firmware -> run self-test
Firmware -> confirm slot
Device -> report success

Yeniden başlatmadan önce herhangi bir koşul başarısız olursa eski bölüm etkin kalır.

Uygulama açılıştan sonra başarısız olursa bootloader sonraki açılışta devreye girer.

23. Sonuç

Güvenli OTA bir dosya indirme endpoint'i değil, yazılım için tam bir yaşam döngüsüdür.

İyi mimari indirme, doğrulama, yazma, açılış ve onay adımlarını ayırır.

Dual-Bank çalışan sürümü korur, imza kaynağı kanıtlar, SHA-256 bozulmayı yakalar, watchdog kurtarmayı destekler ve Canary hatanın etkisini azaltır.

Güç kesintisi, kötü amaçlı dosya, veri uyumluluğu ve aşamalı yayın test edildiğinde cihaz güncellemesi uzak endüstriyel sahalarda bile güvenilir bir hizmet olur.

Introduction: OTA is more than uploading a file

When a device is in a development lab, a programmer can be connected and a failure corrected within minutes. An industrial device may instead be on a rooftop, inside a machine, or at a site that is hard to reach.

In that situation, Firmware updating is a critical operational function rather than an optional feature.

An interruption during writing can leave the device Bricked, an untrusted file can create a security exposure, and an update incompatible with stored data can stop production.

Design OTA as a complete chain of trust:

1. Discover a new version.
2. Download the file in chunks.
3. Resume after interruption.
4. Verify size, hash, and signature.
5. Write to the inactive partition.
6. Perform a trial boot.
7. Confirm the version or roll back.
8. Record and report the result.

1. System requirements

Define constraints before choosing an OTA library.

Ask: how much Flash is available; is there room for two application partitions; what is the site network speed; what happens during power loss; does the device run 24/7; must the update be encrypted; who may publish Firmware; is the new version compatible with the data schema; and what is the maximum acceptable outage?

These answers determine the partition table, protocol, and recovery policy.

2. Why Dual-Bank?

An A/B or Dual-Bank design has at least two application partitions.

+------------------+
| Bootloader       |
+------------------+
| OTA Metadata     |
+------------------+
| App A            |  running
+------------------+
| App B            |  download target
+------------------+
| Filesystem       |
+------------------+

If App A is running, write the new version to App B. Do not touch the running program during download.

After verification, the bootloader changes the boot pointer to App B. If App B fails its first test, return to App A.

This reduces corruption risk during power loss but requires more Flash.

3. Update states

Use an explicit state machine instead of scattered flags.

typedef enum {
    OTA_IDLE,
    OTA_CHECKING,
    OTA_DOWNLOADING,
    OTA_VERIFYING,
    OTA_PENDING_REBOOT,
    OTA_TRIAL_BOOT,
    OTA_CONFIRMED,
    OTA_ROLLBACK,
    OTA_FAILED
} ota_state_t;

Every state needs defined transitions and recorded failure reasons.

For example, do not move from OTA_DOWNLOADING to OTA_PENDING_REBOOT until size, hash, and signature are valid. Do not reach OTA_CONFIRMED until required services run and the health test passes.

4. Discover the version

The device can query a manifest over HTTPS:

{
  "product": "kts200-controller",
  "version": "2.4.1",
  "min_bootloader": "1.3.0",
  "size": 786432,
  "sha256": "...",
  "signature": "...",
  "url": "https://updates.example.com/kts200-2.4.1.bin"
}

Do not trust version alone. Verify product, model, and hardware revision. A Rev A device may not have the GPIO definitions of Rev B. Also prevent unauthorized downgrade when an older release contains a vulnerability.

5. HTTPS is not a substitute for signing

HTTPS protects transport between device and server, but does not by itself prove that the file came from your team if the server or publishing account is compromised.

Sign Firmware with a private key kept off-device and verify it with an embedded or protected public key.

Firmware bytes -> SHA-256 -> digital signature
                                      |
                             public-key verification

Never put the private key in the repository, a developer device, or CI logs. If it is exposed, you need key rotation and release revocation plans.

6. Verify SHA-256

The hash detects corruption or modification.

sha256_init(&context);

while (download_has_data()) {
    size_t received = download_chunk(buffer, sizeof(buffer));
    sha256_update(&context, buffer, received);
    flash_write(target_offset, buffer, received);
    target_offset += received;
}

sha256_final(&context, digest);

Comparing a few leading bytes or the file size is not enough. Compare the complete digest with the value in the trusted manifest. If verification fails, do not make the new partition bootable.

7. Split downloads into chunks

Downloading at once consumes RAM and makes resuming difficult.

Use chunks sized for TCP and Flash, such as 4 or 16 kilobytes depending on the platform. Each chunk needs an offset, length, sequence number, optional checksum, timeout, and retry count.

After a network interruption, the device reads the last confirmed offset and continues. Safe resumption requires HTTP Range or an equivalent server protocol.

8. Write to Flash

Flash does not behave like RAM. A complete sector often must be erased before rewriting, and a bit cannot change from 0 to 1 without erase.

1. Ensure the address is aligned as required.
2. Erase only target sectors.
3. Write suitable batches.
4. Verify by reading back when needed.
5. Do not cut power while sensitive metadata is updated.

Do not write a counter thousands of times to one sector without wear leveling.

9. Protect local data

Firmware and device data are different things. Updating must not touch calibration, counters, or fault logs without a migration plan.

typedef struct {
    uint32_t magic;
    uint16_t schema_version;
    uint16_t payload_length;
    uint32_t crc32;
} settings_header_t;

At boot, the new version reads the old schema and migrates it once. If migration fails, use a backup or safe defaults.

10. Bootloader and boot record

The bootloader needs interruption-resistant metadata.

typedef struct {
    uint32_t magic;
    uint8_t active_slot;
    uint8_t pending_slot;
    uint8_t boot_attempts;
    uint8_t confirmed;
    uint32_t metadata_crc;
} boot_record_t;

Do not write the record in a way that can leave it half updated. Use two copies or a small journal with a sequence number and CRC; the bootloader selects the newest valid record.

11. Trial Boot

Do not declare the new version stable immediately after installation.

Start in trial mode with a limited number of attempts. Check scheduler operation, basic memory, valid settings, critical sensor connections, watchdog health, self-test success, and the ability to send a heartbeat.

If everything passes, the application confirms the version. If it reboots first, the bootloader increments the attempt count and returns to the previous partition after the limit.

12. Watchdog and Rollback

Watchdog is not just a reboot timer; in OTA it is part of the recovery policy.

If the new application hangs before reporting success, watchdog restarts the device. At the next boot the bootloader sees an unconfirmed pending version and selects the previous stable version.

Prevent an endless rollback loop with a counter and record the reason: crash, watchdog timeout, failed self-test, invalid signature, missing configuration, or network confirmation timeout.

13. Encryption and identity

Transport encryption and Firmware encryption are different. HTTPS protects the path; encrypting the file protects confidentiality while it is stored or copied.

Not every Firmware needs confidentiality, but it usually needs authenticity and integrity. If the file is encrypted, manage the decryption key carefully inside the device and never put it in an exposed manifest.

Each device should have a unique identity and a revocable certificate or token.

14. Least privilege for the server

The update server should not be able to modify every database.

• Build and signing service.
• Read-only file store after publication.
• Manifest API.
• Telemetry service.
• Review and permissions panel.

Record who published each version, when, and to which device group. A gradual rollout is better than sending Firmware to every device at once.

15. Canary and staged rollout

Start with a small percentage of devices.

Watch crash rate, rollback rate, boot time, and memory use. Stop deployment automatically if metrics cross allowed limits.

1%   for two hours
10%  for six hours
30%  for one day
100% after results are approved

The first group should represent different sites, networks, and devices, not merely the first ten connected devices.

16. BLE and Web Serial updates

Where the internet is unavailable, a local channel may be needed.

BLE suits initial setup or a small file, but transfer speed, power, and range are limited.

Web Serial lets a technician connected through USB or a suitable adapter transfer Firmware from a browser.

Local updating must still prove the file is valid; it must not bypass signing merely because it is local. Physical access does not necessarily make the local user trusted.

17. Handle power loss

Test power loss at every stage: during erase, while writing a chunk, after the last chunk but before hashing, after hashing but before changing the boot flag, during trial boot, and during data migration.

Each case must end in safe continuation or a return to a valid version. Never write the active slot before all verification is complete.

18. Security tests

Test rejection of an incorrectly signed file, a file modified after signing, a mismatched product, a version below the minimum, a file larger than the partition, an incomplete manifest, an expired certificate, an untrusted server, and an old replay.

Also test full Flash, DNS failure, timeout, and power fluctuation.

19. Compatibility tests

Do not rely on a text version alone. Compare major, minor, hardware revision, and migration policy.

20. Post-deployment monitoring

Send small, safe telemetry: bootloader version, Firmware version, active partition, last boot reason, trial attempt count, last self-test result, schema version, and last heartbeat time.

Do not send secrets or personal data in update logs.

21. Common mistakes

• Writing to the active partition: It may work in a lab and fail during power loss.
• Trusting the file name: firmware-final.bin proves nothing; the signature is the authority.
• Not testing rollback: An untested feature is not a recovery plan.
• Mixing Firmware and data: An unplanned erase can delete calibration or device identity.
• No attempt limit: The device can enter a reboot loop and drain its battery.
• Full rollout without a canary: One mistake can disable an entire fleet.

22. Complete flow model

Device -> fetch manifest
Device -> verify product and version
Device -> download chunks to inactive slot
Device -> calculate SHA-256
Device -> verify signature
Device -> mark slot pending
Device -> reboot
Bootloader -> start trial slot
Firmware -> run self-test
Firmware -> confirm slot
Device -> report success

If any condition fails before reboot, the old partition remains active. If the application fails after boot, the bootloader intervenes at the next boot.

23. Conclusion

Secure OTA is a complete software lifecycle, not a file-download endpoint.

A good architecture separates download, verification, writing, boot, and confirmation.

Dual-Bank protects the running version, signing proves the source, SHA-256 detects corruption, watchdog supports recovery, and Canary reduces the impact of failure.

When power loss, malicious files, data compatibility, and staged rollout are tested, device updating becomes a service that can be trusted even at remote industrial sites.