Azure Digital Twins Alternatifleri: Yönetilen, Açık Kaynak ve MQTT Tabanlı Seçenekler

Bir Azure Digital Twins alternatifi arıyorsanız, muhtemelen modellenmiş ve sorgulanabilir bir ikiz grafı fikrini seviyorsunuz, ancak daha fazla taşınabilirlik, daha basit bir yığın veya tek bir buluta bağımlı olmayan bir kurulum istiyorsunuz. Bu makale alternatiflerin başlıca ailelerini karşılaştırıyor: diğer yönetilen hizmetler, açık kaynak ikiz platformları ve standart MQTT üzerine kurulu kendin-yap (DIY) yığınları. Ayrıca MQTT ile beslenen minimal bir ikiz grafı için çalışan kod göreceksiniz; böylece DIY yolunu kendiniz değerlendirebilirsiniz.

Kavramla yeni mi tanışıyorsunuz? Dijital ikiz teknolojisi rehberi temel bilgileri açıklıyor.

Azure Digital Twins Aslında Ne Sunar?

Karşılaştırmadan önce neyin yerine geçeceğiniz konusunda net olmak faydalıdır. Azure Digital Twins, ortamları modellemek için bir platform hizmetidir. Temel yapı taşları şunlardır:

• DTDL modelleri: ikiz tiplerinin, özelliklerinin, telemetrisinin, bileşenlerinin ve ilişkilerinin JSON-LD tabanlı tanımları.
• Bir ikiz grafı: ilişkilerle birbirine bağlanan bu modellerin örnekleri; örneğin sensörleri içeren odaları içeren bir kat.
• Bir sorgu dili: grafı dolaşmak ve filtrelemek için.
• Olay rotaları: ikiz değişikliklerini alt akışta işlenmeleri için diğer Azure hizmetlerine gönderir.

Dikkat çekici biçimde, cihaz verisinin ulaştığı yer burası değildir. Cihaz mesajları genellikle önce bir veri alım hizmetine düşer ve ikiz özelliklerini güncellemek için çoğu zaman serverless bir fonksiyon olan yapıştırıcı kod yazarsınız. Geçmiş veri için kendi depolamanızı, kendi görselleştirmenizi ve kendi analitiğinizi de siz getirirsiniz. Başka bir deyişle bu, bir ikiz çözümünün tamamı değil, bir katmanıdır.

Bu çerçeve önemlidir. Alternatiflerin çoğu modelleme ve graf katmanının yerini alır; veri alımı, geçmiş ve görselleştirme katmanlarına ise her mimaride ihtiyaç vardır.

Ekipler Neden Alternatif Arıyor?

En sık duyduğumuz motivasyonlar ideolojik değil pratiktir:

1. Taşınabilirlik. Tesisler farklı bulutlarda veya şirket içinde çalışır ve ikizin hepsinde çalışması gerekir.
2. Standart protokoller. Ekipler, cihazların ve gateway'lerin buluta özel bir SDK yerine düz MQTT konuşmasını ister.
3. Basitlik. Birçok proje tam bir graf sorgu motoruna değil, canlı duruma ve bir hiyerarşiye ihtiyaç duyar. Birbirine yapıştırılmış birkaç yönetilen hizmet bunun için ağır kalabilir.
4. Endüstriyel standartlar. Üreticiler DTDL yerine Asset Administration Shell veya ISA-95 yapılarını tercih edebilir.
5. Yetkinlikler ve maliyet öngörülebilirliği. Küçük ekipler çalıştırabildikleri, inceleyebildikleri ve üzerinde akıl yürütebildikleri bileşenleri tercih eder.

Alternatiflerin Karşılaştırması

Açık kaynak dijital ikiz araçları karşılaştırması Ditto, BaSyx ve görselleştirme tarafını daha derinlemesine ele alıyor; asset administration shell rehberi ise AAS modellemesini ayrıntılı olarak anlatıyor.

Pratikte MQTT Tabanlı Yaklaşım

En hafif alternatif, MQTT topic hiyerarşisinin kendisini ikizin omurgası olarak ele alır. Bir Unified Namespace'te her varlık, durumunu konumunu kodlayan bir topic'e yayınlar: site/area/line/cell/asset. Hiyerarşi size "içerir" ilişkilerini, retained mesajlar mevcut durumu, wildcard'lar ise "hat 2'deki her şey" gibi sorguları bedavaya verir.

Ardından yalnızca hiyerarşinin ifade edemediği şeyleri eklersiniz: tipli modeller, "pompa 104 tank 3'ü besler" gibi çapraz bağlantılar ve geçmiş.

İşte Python'da minimal bir ikiz grafı hizmeti. Bir namespace'e abone olur, topic yollarından bir ikiz ağacı oluşturur, her birinin en son durumunu saklar ve basit bir sorguyu destekler. Kendi rastgele prefix'inizle public MQTT test broker'ına karşı çalıştırın.

import json
import threading

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/adt-5m1"
twins = {}  # path -> {"state": {...}, "children": set()}
lock = threading.Lock()


def upsert(path, state):
    parts = path.split("/")
    with lock:
        for i in range(1, len(parts) + 1):
            node = "/".join(parts[:i])
            twins.setdefault(node, {"state": {}, "children": set()})
            if i > 1:
                twins["/".join(parts[:i - 1])]["children"].add(node)
        twins[path]["state"].update(state)


def query(prefix, predicate):
    with lock:
        return {p: t["state"] for p, t in twins.items()
                if p.startswith(prefix) and t["state"] and predicate(t["state"])}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{ROOT}/+/+/+/+/state", qos=1)


def on_message(client, userdata, msg):
    path = msg.topic[len(ROOT) + 1:-len("/state")]
    upsert(path, json.loads(msg.payload))


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="adt-5m1-graph")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_start()

input("Publish some states, then press Enter to query...\n")
hot = query("site1/assembly", lambda s: s.get("temp_c", 0) > 70)
print(json.dumps(hot, indent=2))
print("Children of site1/assembly:", sorted(twins.get("site1/assembly", {}).get("children", [])))
client.loop_stop()

Ona birkaç durum gönderin:

mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-a -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/robot3/state" -m '{"temp_c":74,"mode":"auto"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-b -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/press1/state" -m '{"temp_c":51,"mode":"auto"}'

Her iki mesaj da retained olduğu için graf hizmeti, ayrı bir veritabanı olmadan bağlandığı anda her ikizin mevcut durumunu yeniden oluşturur. Bir ikiz grafı hizmetinin yaptığı işin özü yaklaşık kırk satırda budur. Üretim için bir model kayıt defteri (her varlık tipini tanımlayan DTDL veya JSON Schema dosyaları) ekler, geçmişi bir zaman serisi veritabanında saklar ve sorguyu bir API üzerinden sunarsınız.

Bir Azure projesinden kalan DTDL modelleriniz varsa onları çöpe atmanız gerekmez. DTDL açık bir spesifikasyondur; arayüz dosyalarını dokümantasyon ve doğrulama şemaları olarak tutabilir, her modelin telemetrisini ve özelliklerini topic'lere eşleyebilirsiniz. DTDL rehberi bunun nasıl yapılacağını gösteriyor.

Neyden Vazgeçersiniz, Ne Kazanırsınız?

Geçiş yapmadan önce artılar ve eksiler konusunda dürüst olun.

Vazgeçtikleriniz: yönetilen bir graf sorgu motoru, yerleşik model doğrulama ve Azure ekosisteminin geri kalanıyla entegrasyon. Kuruluşunuz diğer her şeyi Azure üzerinde çalıştırıyorsa ve çok sayıda varlık üzerinde karmaşık, çok adımlı graf sorgularına ihtiyaç duyuyorsa, kalmak doğru cevap olabilir.

Kazandıklarınız: MQTT'nin çalıştığı her yerde, yani pratikte her yerde çalışan bir ikiz: PLC gateway'leri, ESP32 kartları, Node-RED, Python, WebSocket üzerinden tarayıcılar. Her tüketici aynı canlı veriyi okur. Mimariyi açıklamak kolaydır ve broker'dan depolamaya ve 3D'ye kadar her katman bağımsız olarak değiştirilebilir.

Mantıklı bir orta yol yaygındır: MQTT namespace'ini canlı durum için kayıt sistemi olarak tutun ve belirli bir uygulamanın ihtiyaç duyduğu graf veya AAS aracına yansıtın.

Geçiş Kontrol Listesi

1. DTDL modellerinizin ve ikiz örneklerinizin envanterini çıkarın ve hangi ilişkilerin hiyerarşik, hangilerinin çapraz bağlantı olduğunu not edin.
2. Mümkün olduğunda ISA-95 seviyelerini izleyerek hiyerarşik ilişkileri yansıtan bir topic hiyerarşisi tasarlayın.
3. Gateway'leri bir MQTT broker'a yönlendirin; durumu retained, telemetriyi retained olmayan mesajlar olarak yayınlayın.
4. Olay rotalarını MQTT abonelerle değiştirin: bir historian yazıcısı, bir uyarı hizmeti, bir 3D görüntüleyici.
5. Çapraz bağlantı ilişkilerini ve model meta verilerini küçük bir kayıt hizmetinde veya konfigürasyon deposunda saklayın.
6. Tüketicileri geçirmeden önce eski ve yeni yolları birkaç hafta paralel çalıştırın ve durumu karşılaştırın.

Broker Seçimi

MQTT tabanlı bir ikizde broker, her şeyin bağlı olduğu tek bileşendir; bu yüzden birinin masasının altındaki bir hobi sunucusu olmamalıdır. Bir yönetilen MQTT broker, altyapıyı işletmeden size TLS uç noktaları, kimlik doğrulama ve kapasite sağlar.

ConnectMQ; MQTT 3.1.1 ve 5.0'ı, gateway'ler için TCP ve TLS'yi, tarayıcı ikizleri için WebSocket ve Secure WebSocket'i destekler ve portalında ISA-95 ve Unified Namespace topic'lerini algılayarak cihazları hiyerarşi seviyesine göre gösterir. Kendisi bir ikiz platformu olmaya çalışmaz; graf hizmetinizi, historian'ınızı ve görüntüleyicilerinizi sıradan MQTT client'ları olarak bağlarsınız, bu da mimariyi taşınabilir tutar. Broker'ın kendi bulut hesabınızın içinde olması gerekiyorsa BYOC planı onu orada, ConnectMQ tarafından yönetilerek çalıştırır.

ConnectMQ Üzerinde Taşınabilir Bir İkiz Oluşturun

Namespace ile başlayın: birkaç varlık için retained durum yayınlayın ve bir görüntüleyici ile bir graf hizmeti bağlayın. Kredi kartı gerekmeden ücretsiz bir ConnectMQ Serverless broker oluşturun; birkaç dakika içinde ikiziniz için taşınabilir bir temele sahip olursunuz.

Sık Sorulan Sorular

En iyi Azure Digital Twins alternatifi hangisidir?

Neye ihtiyacınız olduğuna bağlıdır. Eclipse Ditto API'li cihaz merkezli ikizlere, Eclipse BaSyx Asset Administration Shell projelerine, MQTT tabanlı bir yığın ise minimum altyapıyla taşınabilir canlı durum isteyen ekiplere uygundur.

DTDL modellerimi başka bir yerde yeniden kullanabilir miyim?

Evet. DTDL açık bir spesifikasyondur, bu yüzden dosyalar şema ve dokümantasyon olarak kullanışlı kalır. Telemetriyi ve özellikleri MQTT topic'lerine eşleyebilir ve payload'ları bunlara karşı doğrulayabilirsiniz.

Bir dijital ikiz için graf veritabanına ihtiyacım var mı?

Her zaman değil. Bir topic hiyerarşisi içerme ilişkilerini, retained mesajlar ise mevcut durumu karşılar. Yalnızca çok sayıda çapraz bağlantılı varlık üzerinde karmaşık sorgulara ihtiyaç duyduğunuzda bir graf deposu ekleyin.

Üretimdeki bir ikiz için MQTT yeterli mi?

MQTT canlı veri dağıtımını üstlenir. Üretimdeki bir ikiz ayrıca geçmiş veri depolamaya, bir model kayıt defterine ve görselleştirmeye ihtiyaç duyar; bunlar broker'a MQTT client'ları olarak bağlanır.