IoT projelerinde uçtan uca mimari: cihazdan buluta veri yolculuğu

Neden katmanlı düşünüyoruz?

IoT projelerinde en sık gördüğümüz hata, cihaz yazılımı ile bulut tarafının tek bir bütün olarak, sınırları çizilmeden geliştirilmesi. Protokol değişikliği gerektiğinde ya da cihaz sayısı yüz katına çıktığında bu yapı kırılıyor. Biz her projeye beş katmanlı bir çerçeveyle başlıyoruz: cihaz, bağlantı, veri alımı, depolama-işleme ve sunum. Her katmanın sorumluluğu ve komşusuyla konuştuğu arayüz baştan tanımlanıyor.

1. Cihaz katmanı

Cihaz tarafında iki karar her şeyi şekillendirir: güç bütçesi ve işlem kapasitesi. Pil ile çalışan bir sensör düğümünde amaç, ölçüm dışındaki her anı uyku modunda geçirmek. Şebeke beslemeli bir endüstriyel cihazda ise kenar işleme (edge processing) devreye girer; veriyi cihazda filtreleyip yalnızca anlamlı değişimleri göndermek, hem bant genişliğini hem bulut maliyetini düşürür.

Donanım seçiminde prototip aşamasında esneklik, üretim aşamasında tedarik sürekliliği öncelenmeli. Prototipte kullandığınız geliştirme kartının üretim eşdeğerini baştan planlamazsanız, saha dağıtımı öncesinde yazılımın önemli bölümünü yeniden yazmak zorunda kalabilirsiniz.

2. Bağlantı ve protokol seçimi

MQTT, düşük bant genişliği ve kararsız ağ koşulları için tasarlandığından IoT'de varsayılan tercihimiz. QoS seviyeleri, last will mesajları ve kalıcı oturumlar, saha koşullarında veri kaybını yönetilebilir kılıyor. HTTP ise cihazın nadiren ve büyük bloklar halinde veri gönderdiği senaryolarda hâlâ geçerli bir seçenek; örneğin günde bir kez toplu rapor yükleyen bir cihaz için MQTT altyapısı kurmak gereksiz karmaşıklık.

Protokol kararını teknoloji trendine göre değil; batarya ömrü, mesaj sıklığı ve ağ koşullarına göre veriyoruz.

Hücresel bağlantıda NB-IoT ve LTE-M arasındaki seçim de benzer şekilde kullanım profiline bağlı: sabit konumlu, az veri üreten sayaçlar için NB-IoT; hareketli veya daha yüksek veri hacimli senaryolar için LTE-M daha uygun sonuç veriyor.

3. Veri alım katmanı

Broker'dan gelen ham mesajın doğrulanması, zenginleştirilmesi ve yönlendirilmesi bu katmanın işi. Burada iki prensibimiz var: alım hattı hiçbir zaman veriyi işlemek için bekletilmemeli ve her mesaj, işlenemese bile ham haliyle saklanmalı. Ham veri arşivi, ileride şema değişikliği ya da hata analizi gerektiğinde geriye dönük işleme imkânı sağlıyor.

4. Depolama ve işleme

Sensör verisi doğası gereği zaman serisidir; ilişkisel veritabanına ham ölçüm yazmak, birkaç ay içinde sorgu performansını eritir. Zaman serisi veritabanları sıkıştırma ve downsampling ile hem depolama maliyetini hem sorgu süresini düşürür. Kural şu: ham veri soğuk depoda ucuza dursun, dashboard'un ihtiyacı olan özetler sıcak katmanda hazır beklesin.

5. İzleme ve uzaktan güncelleme

Sahaya dağıtılmış yüzlerce cihazı elle güncelleyemezsiniz. OTA (over-the-air) güncelleme altyapısı, ilk sürümden itibaren mimarinin parçası olmalı: imzalı firmware paketleri, aşamalı dağıtım ve başarısız güncellemede otomatik geri dönüş. Cihaz sağlığının izlenmesi de aynı derecede kritik; batarya seviyesi, sinyal gücü ve son görülme zamanı gibi metrikler olmadan saha operasyonu körleşir.

Sonuç

Uçtan uca IoT mimarisi, tek tek teknoloji seçimlerinden çok katmanlar arası sınırların netliğiyle başarılı oluyor. Her katmanı bağımsız ölçeklenebilir ve değiştirilebilir tuttuğunuzda, cihaz sayısı da gereksinimler de büyüdüğünde sistem sizinle birlikte büyüyor. Kendi IoT platformumuzda ve müşteri projelerimizde uyguladığımız bu çerçeveyi merak ediyorsanız, IoT çözümlerimize göz atabilir ya da bizimle iletişime geçebilirsiniz.