Ana içeriğe atla

IoT Tecrübeleri — 2

Medikal cihazlardan anlık veri almayı, medikal cihazları uzaktan yapılandırıp bu cihazların hem yönetimini kolaylaştırmayı hem de bakım masraflarını azaltmayı hedefleyen bir projenin içerisindeyim.
Bitleye bitleye GB olur.

Farklı markalar ve farklı haberleşme teknolojilerine sahip bu medikal IoT (Internet of Things) cihazlar ve genel amaçlı birçok IoT cihazının bulunduğu bu projeden edindiğim tecrübeleri paylaşmak istiyorum.


Network bilmeniz gerekiyor. Subnet mask, CIDR, UDP broadcast gibi konulara hâkim olmak işinizi çok kolaylaştırıyor. Aynı işleve sahip IoT cihazları bir ağa, farklı özelliklere sahip IoT cihazları farklı bir ağa yerleştirmek; bir bölgedeki cihazlardan gelen bilgileri bölgesel olarak toplayıp daha sonra merkeze göndermek; bir bölgede internet bağlantısı kaybolduğunda farklı bir ağdan verileri internete çıkarmak gibi işlemlerde ağ bilgisi gerekiyor.

Bir IoT cihazı diğer bir IoT cihazını sensör olarak kullanabiliyor. Böyle durumlarda IoT cihazında birden fazla network çıkışı oluyor. Bu network çıkışlarının IP ayarlarının birbiri ile çakışmaması ve bu farklı ağların birbirleri ile iletişim halinde olması için ağ bilgisi olmazsa olmazlardan.

Güvenli haberleşme özelliği (HTTPS, SSL, TLS) olmayan IoT cihazlara güvenli haberleşme özelliği kazandırmak için Proxy sistemi kurmak için uygun ağ yapılandırması yapmak karşılaşabileceğiniz diğer bir ihtiyaç.

Veriyi nasıl işleyeceğinize karar verin.
IoT cihazlardan gelen verileri gerçek zamanlı mı işlemeniz lazım? Bu sorunun cevabı evet ise cehenneme hoş geldiniz. Böyle bir sistem sürekli erişilebilir olmalı ve gelen veriyi işleyebilecek işlem kapasitesi ölçeklenebilir olmalıdır. Doğru sistem tasarımını yapmak çok önemli. Kodlamaya başlamadan önce tasarımınızın doğruluğundan emin olun.

Veriyi kaydetmeden önce işlemeniz gerekiyor mu? Örneğin Fahrenheit olarak gelen sıcaklık verisini Celsius’a çevirmeniz gerekiyor mu? 2.5687987745684456 olarak gelen veriyi 2.57 olarak çevirmek gerekiyor mu? Gelen veriyi JSON formatına çevirmeniz lazım mı?

Veri kaybı kabul edilebilir mi? Kaç saniyelik veri kaybı olabilir? Herhangi bir veri kaybına tahammülünüz yok mu? Kaybolan veriler, eldeki verileri ile yeniden üretilebilir mi? Verileri daha sonra yapay zekâ ve makine öğrenmesi için kullanacak mısınız? Verileri kayıplı ya da kayıpsız olarak mı sıkıştırıp saklayacaksınız?

Bozuk veri, tekrar eden veri kabul edilebilir mi? Bir verinin bozuk olup olmadığını nasıl anlayacaksınız? Mesaj bütünlüğü nasıl sağlanacak? Tekrar eden veriler elenmeli mi? Sensör kablosunun çıkması gibi durumlarda ve farklı hassasiyette verilerin gelmesinde (örneğin aynı durum için bir cihazdan 0.02, diğer cihazdan 0.01865 değerinin gelmesi) neler yapılacak?

Şifrelemek ya da şifrelememek!
İletim halinde (in transit) olan, kayıt altında olan (at rest) ve işlenen (in process) veriler şifrelenmeli mi? Bütünlük doğrulama algoritması ne olmalı? Kendi SSL sertifikanızı oluştururken kullanacağınız şifreleme anahtarlarının seçimi, Proxy sunuculara kendi SSL sertifikanızı yüklerken ve bu SSL sertifikasına istemcilerin güvenmesini sağlamak için geçtiğiniz adımlarda istemeden de olsa şifreleme dünyasına giriş yapıyorsunuz.

Bazı IoT cihazlar kendilerine özel şifreleme algoritmaları ile haberleşiyorlar ve mesaj doğrulamasını özel algoritmalarla yapıyorlar. Bu cihazlardan veri alabilmek için gelen şifreli veriyi çözmeniz gerekiyor. Bu cihazlara veri gönderebilmek için ise mesajınızın özetini özel algoritma ile almanız gerekiyor.

ASCII, Unicode, UTF-8
Bu kavramlar nedir, aralarında ne gibi farklar var? Veriyi bir karakter setinden diğerine nasıl çevirebilirsiniz? Kontrol karakterlerini (örneğin enter tuşu) nasıl alıp gönderebilirsiniz? Bu soruların cevaplarını bilmeden farklı marka cihazlarla çalışmak çok zor.

Kodlarınız sistemli olsun!
Her bir cihaz için ayrı ayrı kod yazmanız gerekebilir. Ancak interface kullanarak, ortak kullanılabilecek metotları ortak bir yerde toplayarak belirli bir sistem kurabilirsiniz. Gelen verilerin kaydedilmesi için Factory Pattern kullanabilirsiniz. IoT cihaz çeşidi arttıkça aslında birçok kod ihtiyacının aynı olduğunu ve bunların bir kez yazılarak defalarca kullanılabileceğini farkediyorsunuz. Ekip arkadaşlarınız ortak kodların farkında olsunlar ve tekerleği yeniden icat etmeye çalışmasınlar.

Bir sonraki IoT yazısında görüşmek üzere.

Yorumlar

Bu blogdaki popüler yayınlar

Bir Uluslararası Yazılım Şirketinin Batış Hikayesi

 Güzel başlamıştı hikaye. Yazılımcılar mutlu, kullanıcılar memnundu. Sonra pandemi başladı. Sorun para değildi. Olmayan şey huzurdu… Durdurun hype trenini, inecek var kırık kalpler durağında  — Photo by Kelly Sikkema on  Unsplash Gerçek olamayacak kadar güzeldi çalışma ortamı. Yazılımcılara istedikleri eğitim ve donanım alınıyordu, personel arası hiyerarşik bir yapı yoktu, sorumluluğun yanında yetki de veriliyordu, esnek çalışma saatleri yazılımcılara göre esnekti, izin isteyen hiç kimse geri çevrilmiyordu, pandemiden önce bile uzaktan çalışma vardı. Ne oldu bu şirkete? Nazar mı değdi? Şirketin yazılım ürünü Türkiye’de doğmuştu. Ürün birçok ülkede hem kamu tarafından hem de özel sektör tarafından kullanılıyordu. Yazılım geliştirme ekipleri hem Türkiye’de hem de diğer ülkelerde bulunuyordu. Yazılımın argesi için gelen geri bildirimlerin çoğu Türkiye’den geliyordu. Yazılımın kalbi Türkiye’de atıyordu.  Koronavirüs pandemisi nedeniyle Türkiye’de kamu kuruluşları hizmet alımı ile aldıklar

Türkiye'de Yazılım Şirketi Açmak ve Çıldırmamak

Aklında bir fikir vardı. Piyasada bunu karşılayan yazılımlar vardı ama hepsi eksikti. Hayalindeki yazılım ürününe hiçbiri yaklaşamıyordu. Gördüğü kadarıyla piyasanın böyle bir ürüne ihtiyacı vardı. Kullanıcılar mevcut ürünlerden şikayetçiydi. Kendi ekibini toplayıp hayalindeki şirketi kurmaya niyetlendi. Rüzgarlara dikkat!- Francesco Ungaro -  Pexels İşinden istifa etmeden önce piyasa araştırmasını yaptı, rakip ürünleri inceledi. En önemlisi ekibini kurdu. Ürününün MVP hali için çalışmaları başlattı. Girişim kurmak ile ilgili birçok kitap ve blog okudu, podcastler dinledi. Girişimci birkaç kişinin çayını kahvesini içti. Öngörebildiği her şey için önlemini aldı ve istifa edip kendi yazılım şirketini kurdu. Şirket kurmak için gerekli süreçler düşündüğünden daha kolay geçti. Şirketin adı ve logosu zaten hazırdı. Şirket teknoparkta yerini almıştı. Kendisi etiketlere çok önem vermiyordu ama yine de LinkedIn’deki profiline “Founder of the …” ibaresini ekledi. MVP’nin ortaya çıkması hedefini

Yazılımcılar İçin Yan Proje Oluşturma Rehberi

İster hobi amaçlı olsun ister maddi amaçlı her yazılımcının bir yan projesi olmalıdır. Peki yan proje oluştururken nelere dikkat edilmelidir, nasıl bir yan projemiz olmalıdır? Organize olalım beyler Yan proje (side project) için öncelikle bir fikir bulmak gerekli. Bu projenin amacı ne olacak? Hangi ihtiyacı çözecek? Yeni bir fikir mi olacak yoksa mevcut bir fikrin daha iyi uygulanmış bir hali mi olacak? Sadece yeni bir teknolojiyi öğrenmek için mi? Deneysel mi olacak ya da eğlenceli mi? Yoksa maddi bir getirisi olacak mı? Bu proje ürün olursa kimler kullanacak? Ürünü kullanacak kişilere erişip geri bildirim alabilecek miyim? . . . Bu soruların doğru bir cevabı yok, cevaplar size bağlı. Ama proje bir amaca hizmet edip bir ihtiyacı çözecekse, hele birde maddi getirisi olacaksa motivasyonunuz yükselecektir. Bunun yanında sadece eğlence amaçlı olan deneysel bir proje yapmak stressiz bir öğrenme ortamı sağlayacaktır. Gün içinde proje için aklınıza gelen her şeyi not alın. Not almazsan