Gömülü cihazlarda OTA güncelleme: sahadaki cihazı kilitlemeden

OTA (over-the-air, kablosuz) güncelleme, sahadaki cihaza yeni firmware göndermenin ötesinde bir sözdür: güncelleme yarıda kesilse bile cihaz açılmaya devam edecek. Bu yazıda küçük donanım ve yazılım ekipleri için sade bir yol öneriyoruz: iki bölümlü düzen, imzalı paket, açılışta kendini doğrulama, kademeli dağıtım ve geri dönüş.

Giriş

Prototip aşamasında firmware güncellemek kolaydır: kart masada, USB kablosu takılı, programlayıcı hazır. Cihaz sahaya çıkınca tablo değişir. Bir çatıda, bir pano içinde ya da müşterinin cebindeki telefona Bluetooth ile bağlı halde duran cihaza kabloyla ulaşmak çoğu zaman pahalı veya imkânsızdır.

TW Bilişim olarak elektronik ve yazılım işlerinde gördüğümüz tablo: OTA genelde ürünün sonuna eklenen bir özellik olarak düşünülüyor. Oysa ilk sahadaki hata düzeltmesi, ilk güvenlik yaması ve ilk yeni özellik bu hattan geçecek. Hat baştan doğru kurulmazsa, ilk hatalı güncelleme "cihaz açılmıyor" servis çağrısına dönüşür.

Bu rehber mikrodenetleyici tabanlı ürünler (ESP32, STM32, nRF ve benzeri) ve onlarla konuşan mobil veya bulut tarafı için yazıldı. Araç adları örnektir; önemli olan düzen.

1. Önce soru: güncelleme nereden gelecek?

Kanal seçimi mimarinin geri kalanını belirler:

1. Doğrudan internet (Wi-Fi / hücresel): cihaz sunucudan kendisi indirir; sunucu tarafı ve sertifika yönetimi gerekir
2. Telefon üzerinden (BLE): mobil uygulama paketi indirir, cihaza parça parça aktarır; bağlantı kopmaları normaldir
3. Ağ geçidi üzerinden: bir ana cihaz alt cihazları günceller (RS-485, CAN, LoRa vb.); en yavaş halka belirleyicidir

Hangi kanal olursa olsun, "aktarım yarıda kesilirse ne olur?" sorusunun cevabı tasarım dokümanında yazılı olmalı.

2. İki bölüm: çalışan sürüme dokunmadan yaz

En sık görülen hata, yeni firmware'i çalışan kodun üzerine yazmaktır. Güç tam o anda kesilirse cihazda ne eski ne yeni sağlam bir kod kalır.

Yaygın ve sade çözüm iki bölümlü (A/B) düzendir:

• Cihaz A bölümünden çalışırken yeni paket B'ye yazılır
• Paket tamamen yazılıp doğrulanınca bootloader'a "bir sonraki açılış B" denir
• B sorunlu çıkarsa cihaz A'ya döner

Flash alanı dar ise tek bölüm + küçük bir kurtarma imajı da bir seçenektir, ama kurtarma yolunu mutlaka sahada denemek gerekir. ESP-IDF'in OTA bölümleri veya MCUboot gibi hazır bootloader'lar bu düzeni sıfırdan yazmadan kurmayı kolaylaştırır.

3. İmza: "doğru dosya" ile "bizim dosyamız" aynı şey değil

Checksum (CRC, SHA-256) paketin bozulmadığını gösterir; paketin sizden geldiğini göstermez. Bunun için imza gerekir:

• Paket build hattında özel anahtarla imzalanır
• Cihazda yalnız açık anahtar durur; bootloader imzayı doğrulamadan paketi çalıştırmaz
• Özel anahtar geliştirici laptop'unda veya repo'da durmaz

Bu, secret ve erişim yazısındaki kuralların donanım tarafındaki karşılığıdır: imza anahtarı sızarsa sahadaki her cihaz başkasının firmware'ini kabul eder. Anahtarı kimin kullanabildiği ve kaybolursa ne yapılacağı baştan belli olmalı.

4. Açılışta kendini doğrula, sonra kalıcı yap

Yeni firmware'in açılması, doğru çalıştığı anlamına gelmez. Sade bir kural:

• Yeni sürüm ilk açılışta "deneme" modunda başlar
• Kısa bir öz-test yapar: sensörler okunuyor mu, haberleşme kuruluyor mu, kritik görevler dönüyor mu?
• Test geçerse sürüm kalıcı olarak işaretlenir; geçmezse veya watchdog tetiklenirse bir sonraki açılışta eski sürüme dönülür

Bu adım atlanırsa, açılan ama işini yapmayan bir cihaz "başarılı güncelleme" olarak raporlanır.

5. Ön koşullar: her an güncelleme yapılmaz

Sahada güncelleme başlatmadan önce cihazın kendisine sorması gereken birkaç soru vardır:

• Besleme yeterli mi? Pilli cihazda düşük şarjda güncelleme başlatmayın
• Cihaz kritik bir iş yapıyor mu? Örneğin bir röle veya motor kontrolü sırasında yeniden başlatma uygun mu?
• Yeni sürüm bu donanım revizyonuyla uyumlu mu? Paket içinde donanım sürümü ve asgari bootloader sürümü yazsın
• Kullanıcı onayı gerekiyor mu? Telefon üzerinden güncellemede ekran kapanırsa veya uygulama arka plana geçerse ne olacak?

6. Kademeli dağıtım: herkese aynı gün değil

Yazılım tarafındaki CI/CD mantığı burada da geçerli; fark, geri almanın daha pahalı olmasıdır.

Aşama	Kime	Ne bekleniyor
İç test	Masadaki ve ofisteki cihazlar	Güç kesme ve bağlantı kopma testleri dahil
Pilot	Küçük bir saha grubu	Birkaç gün sorunsuz çalışma
Genel	Tüm cihazlar, gerekirse parti parti	Hata oranı izlenir, gerekirse durdurulur

Dağıtımı durdurabilmek, dağıtımı başlatabilmek kadar önemlidir. Sunucu veya uygulama tarafında "bu sürümü artık sunma" anahtarı olmalı.

7. Sahadan geri bildirim: hangi cihaz hangi sürümde?

Gözlemlenebilirlik yazısındaki ilke cihazlar için de geçerli: az ama anlamlı veri.

• Cihaz her bağlantıda firmware sürümünü ve donanım revizyonunu bildirsin
• Güncelleme sonucu kayda geçsin: başarılı, geri döndü, yarıda kaldı
• Geri dönüş oranı belli bir eşiği aşarsa dağıtım otomatik veya elle dursun

Bu veri olmadan "bazı müşterilerde sorun var" cümlesi ile "rev B kartlarda 1.4.2 sürümü öz-testte düşüyor" cümlesi arasında günler geçer.

Pratik checklist

Madde	Net mi?	Not
Güncelleme kanalı ve kopma senaryosu yazılı	☐	Wi-Fi / BLE / ağ geçidi
A/B bölüm veya denenmiş kurtarma yolu	☐	Güç kesme testi yapıldı
Paket imzalı, cihazda yalnız açık anahtar	☐	Özel anahtar build hattında
İlk açılışta öz-test ve otomatik geri dönüş	☐	Watchdog dahil
Ön koşullar: pil, iş durumu, donanım uyumu	☐	Paket meta verisinde
Kademeli dağıtım ve durdurma anahtarı	☐	İç test → pilot → genel
Sürüm ve güncelleme sonucu raporlanıyor	☐	Geri dönüş oranı izleniyor

SSS

Küçük bir ürün için OTA şart mı? Sahadaki cihaza fiziksel erişim kolay ve ucuzsa belki değil. Ama ilk güvenlik açığı veya ilk sahada çıkan hata düzeltmesinde her cihaza tek tek gitmek gerekiyorsa, OTA'yı ilk sürümde düşünmek daha ucuza gelir.

Flash alanımız iki bölüme yetmiyor. Ne yapmalı? Tek bölüm + küçük kurtarma imajı, harici flash'a indirme veya sıkıştırılmış paket seçenekleri var. Hangisi olursa olsun, yarıda kesilen güncellemeden sonra cihazın tekrar güncellenebilir durumda kaldığı test edilmeli.

Delta (fark) güncelleme gerekli mi? Bant genişliği veya BLE aktarım süresi gerçekten sorunsa faydalıdır. Ancak karmaşıklık ekler; çoğu küçük ekip için önce tam paketle sağlam bir akış kurmak daha doğru bir başlangıçtır.

Telefon üzerinden güncellemede en sık sorun nedir? Bağlantı kopmaları ve uygulamanın arka plana geçmesi. Aktarımın kaldığı yerden devam edebilmesi ve cihazın yarım paketi asla çalıştırmaması gerekir.

TW Bilişim bu konuda ne yapıyor? Gömülü yazılım, mobil uygulama ve sunucu tarafını birlikte ele alarak mevcut donanımınıza uygun bir güncelleme akışı kuruyoruz: bölüm düzeni, imzalama, build hattı, kademeli dağıtım ve sahadan geri bildirim. Amaç her cihaza karmaşık bir platform kurmak değil; ekibinizin güvenle kullanabileceği bir yol bırakmak.

Sonuç

Sırayı basit tutun: kanalı ve kopma senaryosunu belirle → çalışan sürüme dokunmadan yaz → imzala → açılışta doğrula → kademeli dağıt → sahadan sonucu izle. Bu sıra netse mikrodenetleyici veya bootloader seçimi ikincil kalır.

Cihazınız için güvenli bir güncelleme akışını birlikte kurmak isterseniz: iletişim veya [email protected].