Gömülü Cihazlarda OTA Yazılım Güncellemesi

Sahada üç yüz cihazınız çalışıyor ve yazılımda bir hata buldunuz. Seçenekleriniz ya her cihazın başına bir teknisyen göndermek ya da yeni yazılımı kablosuz olarak, uzaktan yüklemektir. İkinci yolun adı OTA (Over-the-Air) güncellemedir ve bağlı bir ürün için artık lüks değil, temel bir gerekliliktir. Ancak kötü kurulmuş bir OTA sistemi, tek bir hatalı paketle bütün cihaz filosunu çalışmaz hâle getirebilir. Güvenli bir OTA'nın dört temel taşı vardır: yeni yazılımı çalışan yazılımı bozmadan yazmayı sağlayan bölüm yapısı, hangi yazılımın çalışacağına karar veren bir bootloader, paketin gerçekten sizden geldiğini kanıtlayan imza doğrulama ve yeni sürüm sorunluysa eski sürüme dönebilen bir geri dönüş mekanizması. Bu yazıda bunları adım adım nasıl kurduğumuzu anlatıyoruz.

OTA güncelleme nasıl çalışır? Genel akış

Platformdan bağımsız olarak hemen her güvenli OTA sistemi aynı ana akışı izler:

1. Cihaz, sunucuya kendi sürümünü bildirir veya sunucudan "yeni sürüm var" mesajı alır.
2. Yeni yazılım paketini, çalışan yazılıma dokunmadan, ayrı bir bellek bölümüne indirir.
3. İndirme tamamlandığında paketin bütünlüğünü ve imzasını doğrular.
4. Bootloader'a bir sonraki açılışta yeni bölümden başlamasını söyler ve yeniden başlar.
5. Yeni yazılım kendini test eder. Başarılıysa kendini "geçerli" olarak işaretler; başarısızsa veya hiç işaretleme yapamadan çökerse bootloader eski sürüme döner.
6. Cihaz, sonucu (başarılı, geri dönüldü, hata kodu) sunucuya bildirir.

Bu akıştaki her adımın arkasında bir tasarım kararı vardır. Aşağıda bu kararları sırayla ele alıyoruz.

Adım 1: Bellek ve bölüm yapısını planlayın

OTA kararı, donanım seçilirken başlar. Flash bellek, en az iki uygulama kopyasını ve bootloader'ı taşıyacak büyüklükte olmalıdır. Kart tasarımı sırasında bu hesabı yapmamak, ürün sahaya çıktıktan sonra "OTA için yer yok" sorunuyla karşılaşmanın en yaygın nedenidir; bellek planlamasının donanım tarafındaki yerini PCB tasarım süreci yazımızda anlattık.

Yaygın üç bölüm modeli vardır:

Somut örnekler: ESP-IDF'de bölüm tablosunda ota_0 ve ota_1 uygulama bölümleri ile hangi bölümün açılacağını tutan otadata bölümü tanımlanır. MCUboot kullanan STM32, nRF veya Zephyr tabanlı projelerde ise birincil ve ikincil slot tanımlanır ve takas ya da doğrudan çalıştırma modlarından biri seçilir. Kaynakları kısıtlı cihazlarda harici bir SPI flash'ı ikincil slot olarak kullanmak sık başvurulan bir çözümdür.

Sık hata: Uygulama boyutunu bugünkü hâline göre hesaplamak. Ürün olgunlaştıkça yazılım büyür; bölümleri ilk günden yüzde yirmi otuz pay bırakarak boyutlandırmak, ileride bölüm tablosunu değiştirmek zorunda kalmaktan çok daha kolaydır. Çünkü bölüm tablosunu ve bootloader'ı sahada güncellemek, uygulamayı güncellemekten çok daha risklidir.

Adım 2: Bootloader'ı seçin ve kilitleyin

Bootloader, cihaz açıldığında ilk çalışan ve hangi uygulamanın başlatılacağına karar veren küçük programdır. OTA güvenliğinin temeli buradadır, çünkü imza doğrulamasını ve geri dönüş kararını o verir.

• Hazır ve denenmiş bir bootloader kullanın. ESP32 için ESP-IDF'nin kendi bootloader'ı, ARM Cortex-M tabanlı ürünlerde MCUboot gibi açık kaynak ve yaygın kullanılan çözümler, sıfırdan yazılan bir bootloader'dan neredeyse her zaman daha güvenlidir. STM32 ile başlayacaklar için temel kavramları STM32 ile gömülü sistem geliştirmeye giriş yazımızda anlattık.
• Bootloader'ı olabildiğince sade tutun. Ağ bağlantısı, dosya sistemi ve indirme işi uygulamada yapılmalı; bootloader yalnızca doğrulama, bölüm seçimi ve geri dönüş yapmalıdır. Kod ne kadar küçükse hata ihtimali o kadar azdır.
• Bootloader'ı sahada güncellemekten kaçının. Uygulama A/B ile güvenle güncellenir, ama bootloader genellikle tek kopyadır; yazma sırasında oluşacak bir kesinti cihazı açılamaz hâle getirebilir. Bu yüzden bootloader ürün çıkmadan önce iyice test edilmeli ve mümkünse yazmaya karşı korunmalıdır.
• Hata ayıklama erişimini üretimde kapatın. JTAG/SWD portu açık bırakılmış bir cihazda, fiziksel erişimi olan biri tüm güvenlik zincirini atlayabilir. Mikrodenetleyicinin okuma koruması veya güvenli açılış özellikleri üretim sürecinin bir adımı olmalıdır.

Adım 3: Yazılım imzalama ve doğrulama

Cihaz yalnızca sizin imzaladığınız yazılımı çalıştırmalıdır. Aksi hâlde güncelleme kanalı, saldırganların cihazlarınıza istedikleri kodu yüklemesi için bir kapıya dönüşür. Bu iş asimetrik kriptografiyle yapılır:

1. Anahtar çifti üretin. Özel anahtar yalnızca imzalama ortamında durur; açık anahtar bootloader'a veya cihazın güvenli bölgesine (tek seferlik yazılabilen eFuse, OTP alanı) yerleştirilir. Yaygın algoritmalar ECDSA (P-256), Ed25519 ve RSA'dır.
2. Derleme çıktısını imzalayın. MCUboot ekosisteminde bu iş imgtool ile, ESP-IDF'de güvenli açılış ve imzalı uygulama ayarlarıyla yapılır. İmza, imaj başlığına veya sonuna eklenir; başlıkta sürüm numarası da yer alır.
3. Cihazda iki noktada doğrulayın. Uygulama, indirdiği paketi bölümü açılabilir olarak işaretlemeden önce kontrol eder. Bootloader ise açılışta, imajı çalıştırmadan önce tekrar doğrular. İkinci kontrol, flash'ın başka bir yolla değiştirilmesine karşı da koruma sağlar.
4. Özel anahtarı koruyun. Anahtar bir geliştiricinin dizüstü bilgisayarında, sürüm kontrol deposunda veya paylaşılan bir klasörde durmamalı. Donanım güvenlik modülü (HSM), bulut anahtar yönetim servisi veya en azından erişimi kısıtlı, kayıt tutan bir imzalama sunucusu kullanılmalıdır. Anahtar sızarsa saha cihazlarındaki açık anahtarı değiştirmek çoğu zaman mümkün değildir; bu yüzden bu adım ürünün geri kalanından daha fazla dikkat ister.

İmza, paketin kaynağını kanıtlar; gizliliğini değil. Yazılımınızda ticari sır niteliğinde algoritmalar varsa paketin ayrıca şifrelenmesi ve cihazın flash şifreleme özelliğinin açılması düşünülmelidir. Taşıma katmanında ise paket her zaman TLS üzerinden, sunucu sertifikası doğrulanarak indirilmelidir.

Adım 4: Geri dönüş (rollback) mekanizmasını kurun

İmza doğrulama, "bu yazılım bizden mi geldi?" sorusunu cevaplar; "bu yazılım bu cihazda çalışıyor mu?" sorusunu değil. İmzalı ama hatalı bir sürüm, cihazı açılış döngüsüne sokabilir veya ağ bağlantısını koparıp cihazı bir daha güncellenemez hâle getirebilir. Geri dönüş mekanizması bunun için vardır.

Temel kalıp "dene ve onayla" mantığıdır:

1. Yeni imaj ilk açılışta "doğrulama bekliyor" durumunda başlar.
2. Uygulama, kritik işlevlerini test eder: çevre birimleri başlatıldı mı, sensörler okunuyor mu, sunucuya bağlanılabildi mi?
3. Testler geçerse uygulama imajı kalıcı olarak geçerli işaretler.
4. Uygulama işaretleme yapmadan çöker veya yeniden başlarsa bootloader yeni imajı geçersiz sayar ve önceki sürümü açar.

ESP-IDF'de bu davranış CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE ayarıyla açılır; uygulama testlerini geçtikten sonra esp_ota_mark_app_valid_cancel_rollback() çağırır, sorun tespit ederse esp_ota_mark_app_invalid_rollback_and_reboot() ile eski sürüme döner. MCUboot'ta ise yeni imaj "test" olarak işaretlenir ve uygulama kendini onaylamazsa bir sonraki açılışta önceki imaja geri dönülür.

Bu kalıbı tamamlayan iki önlem daha öneririz:

• Watchdog: Donanım watchdog'u, yeni yazılım bir döngüde takılırsa cihazı yeniden başlatır ve geri dönüş mekanizmasının devreye girmesini sağlar.
• Anlamlı sağlık testi: "Uygulama açıldı" yeterli bir test değildir. En az bir kez sunucuya başarıyla bağlanmayı onay şartı yapmak, cihazı bir daha güncellenemeyecek duruma düşürecek ağ hatalarını yakalar.

Bir de ters yönlü koruma gerekir: sürüm düşürme (anti-rollback) koruması. Saldırgan, eski ve güvenlik açığı bilinen ama sizin tarafınızdan imzalanmış bir sürümü cihaza yükleyebilir. Bunu önlemek için bootloader, imaj başlığındaki güvenlik sürümünü cihazda saklanan en düşük kabul edilebilir sürümle karşılaştırır. ESP32'de bu değer eFuse'da tutulur ve geri alınamaz; her artış kalıcıdır ve sınırlı sayıdadır. Bu yüzden güvenlik sürümü her yayında değil, yalnızca gerçekten bir güvenlik açığı kapatıldığında artırılmalıdır.

Adım 5: Dağıtım altyapısını ve kademeli yayını kurun

Cihaz tarafı hazır olduğunda sıra, güncellemeleri kime, ne zaman, nasıl göndereceğinize gelir.

• Bildirim ve indirme kanallarını ayırın. "Yeni sürüm var" mesajı MQTT gibi hafif bir kanalla gelebilir; büyük dosyanın kendisi ise HTTPS üzerinden, kesintiden sonra kaldığı yerden devam edebilen parçalı indirmeyle alınmalıdır. Mesajlaşma tarafının ayrıntıları için MQTT rehberimize bakabilirsiniz.
• Bir manifest kullanın. Sunucu, sürüm numarası, hedef donanım revizyonu, dosya boyutu, özet (hash) ve imza bilgisini içeren bir manifest yayımlamalıdır. Cihaz, kendi donanım revizyonuna uymayan bir paketi indirmemelidir.
• Kademeli yayın (staged rollout): Yeni sürümü önce iç test cihazlarına, sonra filonun küçük bir yüzdesine, sorunsuzsa adım adım tamamına gönderin. Her aşamada geri dönüş oranını ve hata raporlarını izleyin; beklenmedik bir artışta yayını durdurun.
• Zamanlama: Kritik işlevi olan cihazlar çalışırken yeniden başlatılmamalıdır. Bir sulama vanası açıkken ya da bir makine çalışırken güncelleme yapılmamalı; cihaz uygun bir pencere beklemeli veya kullanıcı onayı istemelidir.
• Pil ve enerji kontrolü: Pil seviyesi düşükken güncellemeye başlamayın. İndirme ve yazma işlemi ciddi enerji harcar.
• Sonuç raporu: Her cihaz güncelleme sonucunu ve çalışan sürümünü bildirmelidir. Hangi cihazın hangi sürümde olduğunu bilmeden filo yönetimi yapılamaz.

Bant genişliği çok kısıtlı ağlarda, ör. LoRaWAN'da, tam imaj göndermek pratik değildir; paket boyutu ve görev döngüsü sınırları yüzünden güncelleme saatler sürebilir. Bu ağlarda delta (fark) güncellemeleri ve parçalı çok noktaya yayın mekanizmaları kullanılır, ama yine de yazılım güncellemesi istisnai bir olay olarak planlanmalıdır. Ağın kısıtlarını LoRaWAN rehberimizde anlattık. Güncelleme altyapısını tasarlarken sunucu ve depo tarafının güvenliği için The Update Framework (TUF) gibi çerçevelerin önerdiği ilkeler de yol göstericidir: anahtarların rollere ayrılması, imzaların süreli olması ve depo ele geçirilse bile cihazların sahte paketi reddedebilmesi.

Adım 6: Test planını yazın

OTA'nın en zor yanı, hata durumlarının nadir ve tekrar üretmesi zor olmasıdır. Bu yüzden test planı açıkça bu durumları hedeflemelidir:

• İndirme sırasında bağlantıyı kesin; cihaz kaldığı yerden devam ediyor mu veya temiz biçimde iptal ediyor mu?
• Yazma sırasında ve yeniden başlatma anında elektriği kesin; cihaz her durumda açılabilir bir sürüme dönüyor mu?
• İmzası bozulmuş, eksik yüklenmiş ve başka donanıma ait paket gönderin; cihaz hepsini reddediyor mu?
• Kasıtlı olarak açılışta çöken bir sürüm yükleyin; geri dönüş çalışıyor mu?
• Sunucuya bağlanamayan bir sürüm yükleyin; onay mekanizması bunu yakalıyor mu?
• Eski bir güvenlik sürümünü yüklemeyi deneyin; anti-rollback reddediyor mu?
• Arka arkaya birkaç sürüm atlayan bir güncelleme yapın; veri formatı ve ayar geçişleri doğru çalışıyor mu?

Bu testlerin otomatik bir test düzeneğinde, ör. röleyle elektriği kesen bir test fikstürüyle, her sürümde tekrarlanması idealdir. Sahada yaşanacak tek bir toplu arızanın maliyeti, bu düzeneğin maliyetini kolayca aşar.

Sık yapılan hatalar

• OTA'yı "sonraki sürümde ekleriz" diye ertelemek: İlk sahaya çıkan sürümde OTA yoksa o cihazlar sonsuza kadar o sürümde kalır.
• İmza yerine yalnızca özet (CRC veya hash) kontrolü: Özet, aktarım hatasını yakalar ama sahte paketi yakalamaz; çünkü saldırgan da doğru özeti hesaplayabilir.
• Özel anahtarın kaynak kodla birlikte saklanması.
• Geri dönüşün hiç test edilmemesi: Kâğıt üzerinde var olan ama sahada ilk kez ihtiyaç duyulduğunda çalışmadığı anlaşılan bir mekanizma, hiç olmamasından daha tehlikelidir; çünkü güven yanılsaması yaratır.
• Tüm filoya aynı anda yayın: Tek bir hatalı sürüm, bütün müşterileri aynı gün etkiler.
• Yapılandırma ve veri geçişini unutmak: Yeni sürüm, eski sürümün kaydettiği ayarları okuyabilmelidir; aksi hâlde cihaz güncellenir ama fabrika ayarlarına döner.

Ürününüzü Avrupa Birliği pazarında satıyorsanız şunu da hesaba katın: Siber Dayanıklılık Yasası (Cyber Resilience Act), dijital unsurlu ürünlerin üreticilerine ürün ömrü boyunca güvenlik açıklarını yönetme ve güvenlik güncellemesi sağlama yükümlülükleri getiriyor ve yükümlülükler kademeli olarak uygulanmaya başlıyor. Güvenli bir OTA altyapısı bu yükümlülüklerin teknik temelidir. Genel güvenlik hijyeni için KOBİ siber güvenlik kontrol listemiz de iyi bir başlangıçtır.

Sık Sorulan Sorular

Her mikrodenetleyicide OTA yapılabilir mi?

Teknik olarak çoğunda mümkündür; belirleyici olan flash kapasitesi ve bir haberleşme arayüzünün varlığıdır. A/B yapısı için uygulamanın iki kopyasına yer gerekir. Dahili flash yetmiyorsa harici bir SPI flash ikincil bölüm olarak kullanılabilir. Bu karar donanım tasarlanırken verilmelidir.

Güncelleme sırasında elektrik kesilirse cihaz bozulur mu?

Doğru kurulmuş bir A/B veya swap yapısında hayır. Yeni sürüm ayrı bir bölüme yazıldığı ve açılış bölümü ancak doğrulamadan sonra değiştirildiği için, kesinti anında cihaz çalışan eski sürümle açılmaya devam eder. Risk, tek bölümlü yapılarda ve bootloader güncellemelerinde ortaya çıkar.

Delta güncelleme nedir, ne zaman gerekir?

Delta güncelleme, tüm imaj yerine yalnızca eski ve yeni sürüm arasındaki farkın gönderilmesidir. Hücresel veri maliyetinin yüksek olduğu veya LoRaWAN gibi bant genişliği çok kısıtlı ağlarda anlamlıdır. Karmaşıklığı artırdığı için Wi-Fi veya Ethernet bağlantılı cihazlarda genellikle tam imaj tercih edilir.

Hazır bir OTA platformu mu, kendi sunucumuz mu?

Hazır cihaz yönetim platformları hızlı başlangıç, kademeli yayın ve raporlama özellikleri sunar; ama sağlayıcıya bağımlılık ve cihaz başına maliyet getirir. Kendi sunucunuz tam kontrol sağlar, ama güvenliği ve bakımı sizin sorumluluğunuzdadır. Filo büyüklüğü ve ekibinizin işletme kapasitesi, kararı belirleyen iki ana ölçüttür.

Kullanıcı onayı almadan güncelleme yapmak doğru mu?

Ürünün türüne bağlıdır. Altyapı sensörlerinde otomatik güncelleme genellikle tercih edilir. Kullanıcının kontrol ettiği veya kritik bir işlem yürüten cihazlarda ise güncellemeyi uygun bir zaman penceresine bırakmak ya da onay istemek daha doğrudur. Her durumda güvenlik güncellemelerinin gecikmeden uygulanabilmesi sağlanmalıdır.

Bootloader'ın kendisi güncellenebilir mi?

Bazı platformlar bunu destekler, ama risklidir; çünkü bootloader genellikle tek kopyadır ve yazma sırasındaki bir kesinti cihazı açılamaz hâle getirebilir. Bu yüzden bootloader'ı sade tutmak, ürün çıkmadan önce iyice test etmek ve sahada güncellemeyi yalnızca zorunlu durumlara bırakmak en güvenli yaklaşımdır.

Sonuç

OTA güncelleme, bağlı bir ürünün sahadaki ömrünü belirleyen altyapıdır. Doğru bölüm yapısı, sade ve kilitli bir bootloader, güvenle saklanan anahtarlarla yapılan imza doğrulaması, test edilmiş bir geri dönüş mekanizması ve kademeli yayın birlikte kurulduğunda, sahadaki cihazlarınızı güvenle geliştirmeye devam edebilirsiniz. Nexova Studio olarak gömülü yazılım, bootloader yapılandırması, güncelleme sunucusu ve filo yönetimi panelini birlikte tasarlıyoruz. Ayrıntılar için gömülü sistem sayfamıza göz atabilir, ürününüzü konuşmak için bize yazabilirsiniz.

Kaynaklar

• Espressif ESP-IDF: Over The Air Updates (OTA)
• MCUboot: Secure Bootloader for 32-bit Microcontrollers
• The Update Framework (TUF)
• Avrupa Komisyonu: Cyber Resilience Act