Bu makalemiz içerisinde sizlerle Azure IoT ve Amazon IoT çözümleri hakkında genel mimari ve IoT mimarisine ilişkin yaklaşımları karşılaştıracağız.
Komple bir IoT çözümü birden çok parçadan oluşmaktadır. Herşeyden önce milyarca internete bağlı olan cihazların ölçeğini ve ölçek ekonomisini hatırlamakta fayda var. Bu cihazlardan veri toplamak, ölçmek, ölçüm bilgilerini toparlamak ve sınıflandırmak büyük bir ekosistemi düzenlemek hiç kolay değil.
IoT için ve IoT iletişim alt yapısı için öncelikle sıcak yol ve soğuk yol (aktif-pasif) diyebilirizde veri analizi, veri akışı verinin eş zamanlı analizi, verinin modellenmesi, makine öğrenimi, büyük veri, ön görüsel tahminleme, yapay zeka ve modelleme gibi bir çok başlık altında arayışların detaylandırılması gereklidir.
Veri toplamak için sensörlere, sensörlerin veriyi aktarabilmesi için ağ geçitlerine, ağ geçitlerinin kablosuz iletim protokollerine, iletim protokollerinin IP Yığın ve IP Protokollerine ihtiyaçları vardır.
Yukarıda bahsi geçen bağlılık şeması ve mimari şemayı aşağıdaki resimde Azure IoT referans mimarisi ele almış durumdadır.
MS Azure IoT çift yönlü olarak güvenli, kararlı, cihaz başına oturum ve kimlik güvenliğine kadar detaylı hizmet şeması açıklanmış durumdadır.
Cihazların mesaj yollaması ve mesaj alması durumlarını iki tipte inceleyebiliriz, D2C (Device to Cloud), C2D (Cloud to Device).
Aşağıdaki açıklama IoT Hub ile cihazlar arasındaki mesaj trafiğini özetler.
D2C : Bu bağlantı metodu cihaz’dan veriyi ve telemetri bilgilerini alarak, veriyi buluta taşımak için kullanır.
C2D: Aygıt üzerinden alınan çalıştırma bilgileri, cihaz üzerinden herhangi bir aksiyon alındıysa bu bilgiyi “IoT HUB” üzerinden besleyerek iletilmesini ve çift yönlü iletişim kurmasına aracılık eder.
İletişimin Bulut üzerindeki mesajlaşma trafiğine bakacak olursak, IoT Hub ile birlikte çalışmaya çok benzer şekildedir. Ancak ufak farklılıklara işaret eder.
C2D: Arka uç sistemlerden alınan bilgiler, her mesaj bilgisi alındığında kuyrukta bekletilirler, kuyrukta bekleyen mesajların bir yaşam süresi vardır. Bu yaşam süresi “TTL” (Time to Live) kavramı ile ifade edilir. Eğer cihaz canlı “online” cihaz olarak sisteme tanıtılmış / kendini tanıtmış ise, belli bir müddet iletişim kurmamışsa cihaz “timeout” mesajı yollanır ve cihaz listesinde “offline” durumuna geçer, bu sayede bağlantı tablosunu meşgul etmez, ne zaman iletişime geçilmesi istenirse, geri dön “come back” mesajı yollanır ve ilk iletişime göre çok daha hızlı bir şekilde geri dönmeleri ve sistemde var oldukları bilgisi ulaştırılır.
D2C: “Event Hub” modülü sayesinde veriler uç cihazlardan toplanırlar, veriler iletilirken geri dönüş bilgileri farklı veri yolları üzerinden aktarılırlar, bu metod işlemlerin kuyrukta bekleme sürelerini rahatlatmak ve düzen altında tutmak için yapılır. “Event Hub” ın bu yeteneği sayesinde bahsi geçen çalışma düzeniyle birlikte, “Event Processor Host” kurulumunuda otomatil olarak devreye almış bulunuyorsunuz.
IoT Hub cihaz kimlik tanıtımı ve cihaz sınıflandırması sayesinde tüm verileri cihazlar özelinde kimlik bilgileri için saklar, Ancak bu bilgi şu bilgiyi adreslemez, cihazların metada, işletim sistemi, işletim sistemi seviyesi, IoT Hub bağlantısı gibi bilgileri içermemektedir. Bağlantı bilgisi, bağlantı durumu, son bağlantı, bağlantı dışı bilgi durumunu özetlerler.
Gelelim “AWS IoT” servislerini genel çalışma durumuna, aşağıda yer alan resim temel IoT etkileşimini ve modüller arasındaki bağlantıyı özetlemektedir.
AWS IoT çalışması, Azure IoT Hub çalışması ile çok benzerlik göstermektedir, ancak veriyi iletim şekli ve işlenen modüller arasındaki temel farklılıklar vardır.
Ana konsept itibari ile IoT çözümleri cihazların durumlarını ve bağlantı durumlarını ele alırlar, bu bağlamda, konuşulacaktır.
Cihazlar mesajlarını iletirlerken ve raporlarını iletirlerken, ”named things” isimlendirilmiş şeyler başlığı altında, mesaj iletişimini “message broker” sağlar. “Broker” tüm uçlardan ve abonelerinden aldığı mesajları tüm istemciler için depolar.
AWS IoT hizmeti cihazlardan bilgi toplarken ve mesaj iletimi/dağıtımı için yoğunlukla “MQTT” protokolünü kullanırlar.
Cihazın her daim durum bilgisini saklar ve bir başka cihazın gölgesiymiş gibi davranır. Gölge gibi davranma durumu aslında, cihazdan alınan son durum bilgisini sakladığını ve ihtiyaç duyulması durumunda son durum bilgisini paylaşmasını ifade eder.
Cihaz bilgilerinin local veritabanın tutulması ve gölge kopyalarının saklanması bilgisini “JSON document” sayesinde gerçekleştirir. Mesajların iletilmesi,içeriklerinin paylaşılması, durum bilgisinin raporlanması gerçek cihazlar ile değiştirilmesine kadar olan tüm bilgiyi depolama ve raporlama işlevini “JSON document” ile sağlar.
AWS IoT hizmeti ölçüm bilgilerini, sistemlerin mesaj yayınlarını aygıtlardan alıp, buluta kadar aktarır. Değişiklikler tabiki de istek mesajlarının gönderilmesi ile başlatılır.
AWS IoT çözümü cihazlarla ilgili bilgi içeren ve cihazların metadata verilerinin saklanmasına izin veren bir kayıt defteri yapısına sahiptir. İşlemleri oluşturmak silmek, güncellemek, ve raporlamak için AWS CLI ‘dan faydalanarak yapılabilir.
Bu makalemiz ile birlikte Azure IoT ve ASW IoT çözümleri arasında temel farklıklardan bahsettik, mimari ve cihaz bağlantı yapılarına değindik, bundan sonra ki serinin ikinci makalesinde sizlerin huzuruna, donanım ve protokol tabanlı olarak iki büyük üreticinin karşılaştırmasını yapacağım.