IoT Mimari Diyagramı: Cihazlar, MQTT, Akış İşleme ve Depolama

Çoğu IoT diyagramında üç kutu vardır: cihazlar, bir bulut simgesi ve bir pano. Önemli sorular ise bunların arasında yaşar. Broker hangi cihazın konuştuğunu nasıl bilir? Bir saha bir saat boyunca bağlantısını kaybederse ne olur? Hangi mesajlar kaybolabilir ya da iki kez teslim edilebilir? Bir komut binlerce sensör arasından birine nasıl ulaşır?

Bir IoT mimari diyagramı bu soruları sayfada yanıtlamalıdır. Bu yazı somut bir vaka için, soğuk depolardaki sıcaklık izleme için bir diyagram oluşturuyor ve her adımın ardındaki kararları ele alıyor: MQTT ve hizmet kalitesi seviyeleri, konu tasarımı, cihaz kimliği, çevrimdışı sahalar ve olay zamanı ve verinin nereye vardığı.

Bir IoT sisteminin katmanları

Her sistemin her katmana ihtiyacı yoktur. Hücresel ya da Wi-Fi modülü olan cihazlar çoğu zaman ağ geçidi olmadan doğrudan broker'a yayımlar. Gerçekten çalıştırdığınız katmanları çizin.

Neden MQTT

MQTT, istemcilerin bir broker'a bağlanıp konulara göre mesaj alışverişi yaptığı bir yayımla/abone ol protokolüdür. Mart 2019'dan beri bir OASIS standardı olan MQTT 5.0 spesifikasyonu, onu hafif, açık ve uygulaması basit bir protokol olarak tanımlar. 1883 numaralı port TLS'siz MQTT için, 8883 ise TLS üzerinden MQTT için IANA'ya kayıtlıdır. Sahadan dışarı çıkan her şey 8883'ü kullanmalıdır.

Her mesaj bir hizmet kalitesi (QoS) seviyesiyle yayımlanır:

QoS uçtan uca değil, her adım için geçerlidir: bir abone mesajı, yayımlandığı QoS ile aboneliğine verilen QoS'tan düşük olanıyla alır. QoS 1 ile broker kopya teslim edebilir; bu yüzden her tüketicinin aynı okumayı iki kez almayı kaldırabilmesi gerekir. Cihazın ürettiği bir mesaj kimliği ya da sensör başına bir zaman damgası bunu kolaylaştırır.

MQTT 5, diyagrama koymaya değer birkaç özellik ekler:

• Saklanan mesajlar (retained). Broker bir konudaki son mesajı tutar ve yeni abonelere gönderir; bu, bir cihazın güncel durumu için uygundur.
• Vasiyet mesajları (will). Bir istemcinin bağlantısı düzgün bir bağlantı kesme olmadan koptuğunda broker o istemcinin vasiyet mesajını yayımlar; böylece bir ağ geçidi çevrimdışı olduğunu duyurabilir.
• Mesaj süresinin dolması. Bir mesajın süresi teslimat başlamadan dolarsa broker onu siler. Bunu yalnızca bir süre geçerli olan komutlar için kullanın.
• Paylaşılan abonelikler. Birkaç tüketici tek bir aboneliği paylaşır ve her mesaj yalnızca birine gider; böylece akış platformuna giden köprü ölçeklenebilir.

Konu tasarımı

Konular hiyerarşiktir ve aboneler tek bir seviye için +, geri kalanı için # kullanır. site/{site}/device/{id}/telemetry gibi bir düzen, tek bir sahaya, tek bir cihaza ya da her şeye abone olmanızı sağlar ve broker'ın her cihazı yalnızca kendi konularıyla sınırlamasına izin verir. $ ile başlayan konular broker'a ayrılmıştır ve joker karakterle başlayan filtreler bunlarla eşleşmez.

Konuları yönlendirme ve izinler için kullanın. Şema sürümünü ve ölçüm zamanını mesaj içeriğine koyun; orada her aboneliği bozmadan değişebilirler.

Cihaz kimliği

Her cihaza ya da ağ geçidine, cihaz CA'nızın imzaladığı kendi X.509 sertifikasını verin ve broker'ın istemci sertifikası istemesini sağlayın. Sertifika öznesi istemci kimliği olur ve broker konulara erişimi buna göre verir. Böylece çalınan bir cihaz tek başına iptal edilebilir ve binlerce cihazın donanım yazılımında paylaşılan bir parola durmaz. Sertifikaların nasıl verileceğine, üretimde mi yoksa ilk açılışta mı, ve süreleri dolmadan nasıl yenileneceğine karar verin ve CA'yı diyagrama çizin.

Çevrimdışı sahalar ve olay zamanı

Sahalar bağlantılarını kaybeder. Okumaları yerelde tamponlayan bir ağ geçidi, bağlantı geri geldiğinde bir saatlik veriyi tek seferde gönderir; böylece veri geç ve sırasız gelir. Her okumayı ölçüldüğü zamanla damgalayın, ağ geçidi saatlerini senkronize tutun ve gecikmeye pay bırakarak olay zamanında işleyin. “Dondurucu on dakikadır -18 °C'nin üstünde” gibi bir alarm, okumaların ulaştığı zamana göre değil, ölçüldükleri zamana göre hesaplanmalıdır. Aynı düşünce her olay güdümlü mimari için geçerlidir.

Örnek: soğuk depo izleme

Her depoda 30 saniyede bir raporlayan yaklaşık kırk dondurucu sensörü ve durum değiştiğinde raporlayan bir düzine kapı sensörü var. Bir saha ağ geçidi okumaları yerel radyo üzerinden toplar, çevrimdışıyken tamponlar ve karşılıklı TLS üzerinden QoS 1 ile MQTT broker'ına yayımlar. Broker her istemci sertifikasını cihaz CA'sına göre doğrular. Paylaşılan aboneliğe sahip bir köprü telemetriyi Kafka'ya kopyalar. Bir tüketici ham mesajları nesne depolamaya arşivler; bir akış işlemcisi olay zamanında bir dakikalık özetleri hesaplar, bunları panolar için bir zaman serisi deposuna yazar ve sıcaklık alarmları üretir. Cihaz yönetimi komutları ve yapılandırmayı broker üzerinden geri gönderir.

Nasıl okunur:

• Solda, saha. Sensörler yalnızca saha ağ geçidiyle konuşur; broker'ın bu sahadan gördüğü tek istemci ağ geçididir.
• Ortada, broker. Telemetri QoS 1 ile yukarı gider. Kesikli kenarlar sahaya inen komutlar ve cihaz CA'sına karşı yapılan sertifika kontrolüdür.
• Sağda, veri yolu. Kafka ham arşivi ve akış işlemcisini besler; akış işlemcisi özetleri zaman serisi deposuna yazar ve alarm üretir.
• Markdown bloğu konu düzenini, konu başına QoS'u ve kimlik kuralını içerir.

Neler etiketlenmeli

• Protokol, port ve QoS, sahadan broker'a giden bağlantıda.
• Cihaz sınıfı başına mesaj hızları. 30 saniyede bir raporlayan kırk sensör, saha başına dakikada 80 mesaj eder; broker'ı boyutlandırmadan önce saha sayısıyla çarpın.
• Kimlik: hangi sertifika, hangi CA ve sertifikaların nasıl yenilenip iptal edildiği.
• Tamponlama: ağ geçidinin çevrimdışıyken veriyi ne kadar süre tutabileceği.
• Saklama süresi, her depo için; akışta saatlerden arşivde yıllara kadar.
• Komut yolu, mesaj süresinin dolması ve bir cihazın bilinmeyen bir komutla ne yaptığı dahil.

Sık yapılan hatalar

• Cihazlar arasında paylaşılan kimlik bilgileri. O zaman sızan tek bir parola her cihazı açar. Cihaz başına bir sertifika kullanın.
• İnternette 1883 portu. TLS olmadan okumalar ve kimlik bilgileri açık metin olarak taşınır.
• Tam olarak bir kez teslimat varsaymak. QoS 1 kopya teslim edebilir; her yerde QoS 2'ye başvurmak yerine tüketicileri idempotent yapın.
• Varış zamanında işlemek. O zaman tamponlanan veri yanlış alarmlar tetikler ya da gerçek alarmları gizler.
• Doğrudan veritabanına yazan cihazlar. Broker'ın kimlik doğrulamasını, tamponlamasını ve dağıtımını kaybedersiniz.
• Güncelleme yolunun olmaması. Donanım yazılımı güncellemeleri ve yapılandırma değişiklikleri mimarinin parçasıdır; onları da çizin.
• Cihazlar için joker karakterli izinler. # konusuna abone olabilen bir cihaz, diğer tüm cihazların verisini okuyabilir.

Ağ topolojisi diyagramı, bir IoT diyagramının genellikle dışarıda bıraktığı sahanın kendi ağını ele alır.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Saha için Temel paketinden bir Çerçeve ekleyin. İçine Ağ paketinden, türü IoT / akıllı ev olarak ayarlanmış her sensör grubu için bir Cihaz ve saha ağ geçidi için türü Modem / ağ geçidi olan bir Cihaz daha ekleyin.
3. C4 Modeli paketinden MQTT broker, cihaz yönetimi ve akış işlemcisi için Konteyner düğümleri, zaman serisi deposu için de bir Veritabanı ekleyin.
4. Güvenlik paketinden cihaz CA'sı için bir Sertifika ekleyin.
5. Veri paketinden Kafka ve ham arşiv için bir Nesne deposu ekleyin. DevOps paketinden panolar için Metrikler ve bir Uyarı düğümü ekleyin.
6. Bunları soldan sağa bağlayın, yukarı bağlantıyı QoS'u ile etiketleyin, komutları ve sertifika kontrolünü kesikli yapın ve konu tasarımını içeren bir Markdown bloğunu Temel paketinden ekleyin.

Örnek 14 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Ağ diyagramı sayfası Ağ paketinin geri kalanını gösteriyor.

SSS

IoT cihazları MQTT mi yoksa HTTP mi kullanmalı? MQTT tek bir bağlantıyı açık tutar; böylece bulut komut gönderebilir ve mesaj başına ek yükü küçüktür. HTTP ise nadiren raporlayan ve hiç komut almayan cihazlar için daha basittir.

Hangi QoS seviyesini kullanmalıyım? Telemetrinin ve komutların çoğu için, kopyaları tolere eden tüketicilerle QoS 1. Kaybetmeyi göze alabileceğiniz yüksek frekanslı okumalar için QoS 0. QoS 2'yi yalnızca kopyaların aşağı akışta ele alınamadığı yerlerde kullanın.

Zaten bir MQTT broker'ım varsa Kafka'ya ihtiyacım var mı? Her zaman değil. Broker mesajları bağlı abonelere yönlendirir; yeniden oynatabileceğiniz uzun vadeli bir log değildir. Birkaç tüketicinin aynı veriye ihtiyacı olduğunda ya da geçmişi yeniden işlemeniz gerektiğinde bir akış platformu ekleyin.

Cihazlar sertifikalarını nasıl alır? Üretimde ya da ilk açılışta bir sağlama (provisioning) servisi aracılığıyla, her biri kendi anahtar çiftiyle. Cihazda güvenli donanım varsa özel anahtarı orada tutun.

Kurallar uçta mı yoksa bulutta mı çalışmalı? Kesinti sırasında da çalışması gereken kurallar, örneğin açık kalan bir kapı için yerel alarm, ağ geçidinde çalışır. Birçok sahadan veri gerektiren kurallar bulutta çalışır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.