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

Uluslararası Yazılım Firmasında Çalışmak

Türkiye merkezli 5 ülkede ofisi olan 50’den fazla mühendisi bulunan ve müşterileri hariç 8 farklı milliyetten kişiler bulunan bir yazılım firmasında yaklaşık 11 aydır çalışmaktayım. Bu süreç boyunca hem çalıştığım şirkette hem de iletişimde bulunduğum diğer uluslararası şirketlerde gözlemlediğim noktaları paylaşmak istedim. Buradaki görüşlerim tamamen kişiseldir ve firmadan firmaya değişebilir. Eleştiriyi önce en günahsız olanınız yapsın! Photo by Kyle Glenn on Unsplash İşe giriş ve mülakat süreçleri zor. İş ilanlarını mantıklı ve açıklayıcı olarak açılıyorlar. Öyle her şeyden anlayan süper yazılımcı aramıyorlar. Şirketin ihtiyacını göz önüne alarak ve her yazılımcının şirkette kullanılan teknolojileri bilemeyeceğini göz önüne alınarak iş ilanını açılıyor. Özgeçmişimde yazan her kelime ile ilgili sorguya çekildim. Başvurduğum pozisyon için gereken yeteneklerle ilgili zor sorular soruldu. Nasıl yaptılar bilmiyorum ama şirket kültürüne uyumumu ve iletişim yeteneğimi de ölçmüşler. Açık

Kamuda Yazılımcı Ol(ma)mak

Yazılımcı olarak 8 yıl kamuda, 2 yıl özel sektörde çalıştım. Bir yandan da freelance olarak çalıştım. Yurtdışındaki firmalarla da güzel yurdumun esnafıyla da çalıştım. En garip manzara bence kamudaki yazılım manzarası. Şu anda bir kamu kurumu için geliştirilen yazılım projesini yönetiyorum. Girdiğim toplantılarda, aldığım e-postalarda, yaptığım telefon konuşmalarında eski kamu anılarım depreşti. Kağıtların arasında hayalleri yıkılmış bir yazılımcı bulabilirsiniz Kamuda çalışırken hem benim hem de arkadaşlarımın başına gelen olaylardan ve şu anda kamuda çalışmaya devam eden tanıdıklarımdan aldığım bilgilerle, kamudaki yazılım dünyasını size sanayi diliyle aktarmaya çalışacağım. Bu yazı şahsi görüşlerimi içerir. Yine de kamuda 8 yılın yeterince objektif bir bakış açısı sunacağını düşünüyorum. Kamuya yazılım projesi geliştirirken karşılaşabileceğiniz durumlar: Bir kamu kurumu ile görüşmeye başlamak için bağlantı gerekir. Kamu kurumuna “sizin şöyle bir ihtiyacınız var ben bunu çözen yazılı