Device shadow mı, dijital ikiz mi sorusu neredeyse her IoT projesinde gündeme gelir, çünkü ikisi de bir cihazın durumunun bulut tarafında bir kopyasını tutar. Bu makale ikisinin kapsam, veri ve amaç bakımından tam olarak nasıl farklılaştığını açıklar, ne zaman bir shadow'un yeterli olduğunu ve ne zaman tam bir ikize ihtiyaç duyduğunuzu gösterir ve retained MQTT topic'leri üzerine kurulu taşınabilir bir device shadow kalıbını adım adım anlatır.
İkiz tarafını derinlemesine incelemek için dijital ikiz teknolojisi rehberine bakın.
Device Shadow Nedir?
Device shadow, bulutta tutulan, tek bir cihaza ait kalıcı bir durum belgesidir. Genellikle üç bölümden oluşur:
- Reported (bildirilen): cihazın bildirdiği son durum.
- Desired (istenen): bir uygulamanın cihazın sahip olmasını istediği durum.
- Delta (fark): cihazın üzerinde aksiyon alması gereken fark.
Bulut IoT platformları shadow'ları (bazı platformlarda device twin olarak da adlandırılır) belirli bir sorunu çözmek için sundu: uygulamaların, cihaz uykudayken veya çevrimdışıyken bile cihaz durumunu okuması ve değiştirmesi gerekir. Shadow her zaman erişilebilirdir; cihaz bağlandığında onunla senkronize olur.
Bir shadow bilerek basit tutulmuştur. Tek bir cihazı bilir, güncel durumu ve bir sürüm numarasını tutar, başka pek bir şey yapmaz.
Dijital İkiz Nedir?
Dijital ikiz daha geniş bir kavramdır: güncel durumu bağlam ve davranışla birleştiren, fiziksel bir varlığın, sürecin veya sistemin canlı sanal temsili. Bir shadow'un tuttuğu durumun üzerine bir ikiz genellikle şunları ekler:
- Bir model: varlığın ne olduğu, özellikleri, birimleri ve semantiği; çoğu zaman DTDL ile veya bir Asset Administration Shell olarak ifade edilir.
- İlişkiler: bu pompa şu istasyona aittir, o istasyon da şu tankı besler.
- Geçmiş: trendler, teşhis ve tahmin için kullanılan zaman serileri.
- Analitik veya simülasyon: türetilmiş değerler, anomali tespiti, "ya olursa" senaryoları.
- Görselleştirme: birçok varlığı bir arada gösteren panolar veya 3D sahneler.
Bir ikiz, hiç de tek bir cihaz olmayan şeyleri temsil edebilir: bir üretim hattı, bir bina katı, bütün bir tesis.
Device Shadow ve Dijital İkiz: Yan Yana
| Boyut | Device shadow | Dijital ikiz |
|---|---|---|
| Kapsam | Tek bir cihaz | Varlık, sistem veya süreç; çoğu zaman birçok cihaz |
| Temel veri | Güncel bildirilen ve istenen durum | Durum artı geçmiş, model ve bağlam |
| Model | Serbest biçimli JSON | Açık şema, semantik ve birimler |
| İlişkiler | Yok | Hiyerarşiler ve varlıklar arası bağlantılar |
| Zaman | Yalnızca en son değer | Güncel ve geçmiş |
| Mantık | Delta hesaplama | Analitik, simülasyon, tahmin |
| Tipik tüketiciler | Mobil uygulamalar, cihaz yönetimi | Mühendisler, operatörler, planlamacılar |
| Görselleştirme | Genellikle yok | Panolar ve 3D görünümler yaygın |
| Oluşturma eforu | Düşük | Ortadan yükseğe |
İlişki birikimlidir: dijital ikizlerin çoğu her cihaz için shadow benzeri bir şey içerir, ancak bir shadow tek başına tam bir ikiz değildir. Dijital ikiz ve dijital gölge yazımız, araştırma literatüründen gelen ilişkili ama farklı bir ayrımı ele alır; orada dijital gölge, varlıktan modele tek yönlü veri akışı anlamına gelir.
Device Shadow Ne Zaman Yeterlidir
Şu durumlarda shadow seçin:
- Akıllı prizler, takip cihazları veya sayaçlar gibi çok sayıda benzer cihazı yönetiyorsunuz.
- Ana ihtiyaç "güncel durumu göster ve ayarları değiştirmeme izin ver".
- Cihazlar uykuya geçiyor veya aralıklı bağlanıyor ve yapılandırmayı yakalamaları gerekiyor.
- Cihazlar arası ilişkilere veya üzerine kurulu analitiğe ihtiyacınız yok.
Tüketici IoT'si, filo yapılandırması ve uzaktan ayarlar klasik shadow alanıdır.
Ne Zaman Tam Bir Dijital İkize İhtiyacınız Olur
Şu durumlarda ikiz seçin:
- Değer, varlıkları bağlam içinde görmekten geliyor: bir hat, bir bina, bir şebeke.
- Sorunları teşhis etmek için durumu geçmişle ilişkilendirmeniz gerekiyor.
- Birden fazla veri kaynağı tek bir varlığı tanımlıyor (PLC, titreşim sensörü, MES).
- Kullanıcılar mekânsal veya 3D görünümler istiyor.
- Kestirimci bakım veya simülasyon planlıyorsunuz.
Endüstriyel tesisler, enerji sistemleri ve binalar neredeyse her zaman buraya varır. Dijital ikiz mimarisi yazısı ihtiyaç duyacağınız ek katmanları gösterir.
Retained MQTT Topic'leriyle Taşınabilir Bir Device Shadow Oluşturmak
Bulut shadow servisleri kendi platformlarına bağlıdır. Retained mesajları kullanarak aynı davranışı standartlara uyan herhangi bir MQTT broker üzerinde elde edebilirsiniz; bu da tasarımı taşınabilir tutar. Topic düzeni:
connectmq/demo/<id>/shadows/<device>/reported retained, device writes
connectmq/demo/<id>/shadows/<device>/desired retained, apps write
connectmq/demo/<id>/shadows/<device>/delta not retained, computed by a shadow service
connectmq/demo/<id>/shadows/<device>/status retained, last will
Retained mesajlar size en önemli shadow özelliğini ücretsiz olarak verir: kim abone olursa olsun, ne zaman abone olursa olsun, en son bildirilen ve istenen belgeleri alır. Küçük bir servis farkları hesaplar:
import json
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/4d2a/shadows"
shadows = {}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/+/reported", qos=1)
client.subscribe(f"{BASE}/+/desired", qos=1)
def on_message(client, userdata, msg):
_, _, _, _, device, kind = msg.topic.split("/")
doc = json.loads(msg.payload) if msg.payload else {}
shadow = shadows.setdefault(device, {"reported": {}, "desired": {}})
shadow[kind] = doc
delta = {
key: value
for key, value in shadow["desired"].items()
if key not in ("version", "ts") and shadow["reported"].get(key) != value
}
if delta:
client.publish(f"{BASE}/{device}/delta", json.dumps(delta), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shadow-service-4d2a")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Ücretsiz herkese açık MQTT broker ile deneyin:
mosquitto_pub -h broker.connectmq.com -p 1883 -i lamp1-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/reported" -m '{"on": false, "brightness": 40}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i app-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/desired" -m '{"version": 1, "on": true, "brightness": 80}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-4d2a \
-t "connectmq/demo/4d2a/shadows/lamp1/#" -v
Servis delta topic'ine {"on": true, "brightness": 80} yayınlar. Bir cihaz servisi tamamen atlayabilir de: retained istenen topic'ine abone olur ve farkı yerel olarak hesaplar; bu küçük filolar için çoğu zaman daha basittir. Dijital ikiz durum senkronizasyonu yazısındaki yeniden bağlanma ve sürümleme kuralları aynen geçerlidir.
Retained Topic Shadow'unun Sınırları
Bu kalıbın size neleri vermediği konusunda dürüst olun. Sorgu API'si yoktur ("açık olan tüm lambaları bul"), broker kimlik bilgilerinizin izin verdiğinin ötesinde belge başına erişim kontrolü yoktur ve retained mesajlar bir veritabanında değil broker'da yaşar. Bunlara ihtiyacınız varsa broker'ın yanına bir ikiz servisi veya veritabanı abonesi ekleyin. Yine de pek çok filo için retained topic'ler yeterlidir ve bütün bir servis katmanından kurtarır.
İkisi Arasında Seçim Yaparken Sık Yapılan Hatalar
Ekipler genellikle birbirine zıt iki hatadan birini yapar. Birincisi, bir shadow'a ikiz demek ve ardından paydaşlar tek bir durum belgesinin sağlayamayacağı geçmiş, bağlam ve analitik beklediğinde şaşırmaktır. Tesis müdürü "3. hat geçen salı neden yavaşladı?" diye sorarsa, shadow'un bir cevabı yoktur.
İkinci hata, asıl gereksinim "cihaz uykudayken mobil uygulamanın termostat ayar noktasını değiştirmesine izin ver" iken ağır bir ikiz platformuyla başlamaktır. Bu projenin bir shadow'a ihtiyacı vardır; modelleme, graf veritabanları ve 3D sahneler eklemek yalnızca teslimatı geciktirir.
Faydalı bir test, kullanıcıların en çok yanıtlanmasını istediği üç soruyu yazmaktır. Üçü de tek bir cihazın güncel durumu veya yapılandırmasıyla ilgiliyse bir shadow oluşturun. Herhangi biri zamanı, varlıklar arası ilişkileri veya beklenen ile gerçek davranışın karşılaştırılmasını içeriyorsa bir ikiz planlayın; ancak yine de yukarıda anlatılan shadow tarzı durum topic'leriyle başlayın, çünkü ikiz bunların üzerine kurulacaktır.
Shadow'dan İkize: Pratik Bir Yol
- Cihaz başına retained bir bildirilen ve istenen topic'iyle başlayın.
- Varlık bilgisi (presence) için Last Will içeren bir durum topic'i ekleyin.
- Bir zaman serisi veritabanına yazan bir geçmiş abonesi ekleyin.
- Hiyerarşi ve birimler içeren bir varlık modeli tanıtın.
- Bütün dallara abone olan bir pano veya 3D görünüm ekleyin.
- Geçmiş ve canlı durumun üzerine analitik katmanı ekleyin.
Her adım aynı topic'leri yeniden kullanır; böylece cihazların hiç değişmesi gerekmez.
Shadow'ları ve İkizleri ConnectMQ Üzerinde Oluşturun
ConnectMQ her ikisi için de mesajlaşma temelini sağlar: retained mesajlar, Last Will, MQTT 3.1.1 ve 5.0, 8883'te TLS ve tarayıcı panoları için 8084'te WSS sunan barındırılan bir MQTT broker. Shadow mantığınız ve ikiz servisleriniz sıradan MQTT istemcileri olarak bağlanır; böylece hiçbir şey tek bir buluta kilitlenmez. Kredi kartı olmadan app.connectmq.com adresinde ücretsiz bir Serverless broker oluşturun ve ilk device shadow'unuzu oraya taşıyın.
Sık Sorulan Sorular
Device shadow bir dijital ikiz midir?
Device shadow, tek bir cihaz için ikiz benzeri durumun basit bir biçimidir. Dijital ikiz ise çoğu zaman birçok cihaz genelinde bir model, ilişkiler, geçmiş ve analitik ekler.
Bulut IoT platformu olmadan device shadow oluşturabilir miyim?
Evet. Bildirilen ve istenen durum için retained MQTT topic'leri ve isteğe bağlı bir delta servisi, shadow davranışını standartlara uyan herhangi bir MQTT broker üzerinde yeniden üretir.
Device twin ile device shadow arasındaki fark nedir?
Esasen farklı platform adlarıyla anılan aynı kavramdır: tek bir cihaz için bildirilen ve istenen özellikleri içeren, bulut tarafında tutulan bir belge.
Device shadow için bir veritabanına ihtiyacım var mı?
Mutlaka değil. Retained mesajlar en son durumu tutar. Cihazlar arası sorgulara, geçmişe veya denetim izlerine ihtiyaç duyduğunuzda bir veritabanı ekleyin.
