Dijital İkiz Mimarisi: Veri, Model ve Görselleştirme Katmanları Açıklandı

Yüzlerce varlığa ölçeklenen bir ikizi, ilk beş varlıktan sonra çöken bir demodan ayıran şey net bir dijital ikiz mimarisidir. Bu rehber, sensörler ve uç ağ geçitlerinden bir mesajlaşma omurgası üzerinden durum depolarına, modellere ve 3D görselleştirmeye kadar bir referans mimariyi katman katman ele alır; böylece her parçanın tek bir görevi olduğu ve bağımsız olarak değiştirilebildiği bir yığın tasarlayabilirsiniz.

İkizlerin arkasındaki kavramlar için dijital ikiz teknolojisi rehberimize bakın.

Bir Dijital İkiz Mimarisinin Altı Katmanı

Başarılı ikizlerin çoğu, hangi üreticiyi veya çerçeveyi kullanırsa kullansın, sonunda şu katmanlara sahip olur:

Temel tasarım kuralı: katmanlar birbirleriyle asla özel kısayollar üzerinden değil, iyi tanımlanmış sözleşmeler (topic'ler ve payload şemaları) aracılığıyla konuşur. Bir panoyu 3D görüntüleyiciyle değiştirmenizi veya cihaz firmware'ine dokunmadan bir analitik işi eklemenizi sağlayan da budur.

Katman 1: Cihaz ve Uç

Fiziksel varlıklar nadiren ikiz dostu bir dil konuşur. Bir CNC kontrolcüsü OPC UA veya üreticiye özel bir protokol sunar; eski bir pompanın PLC'ye giden 4–20 mA sinyali vardır; yeni bir sensör bir ESP32 üzerinde çalışıyor olabilir. Uç katmanı bu boşluğu kapatır.

Uçtaki sorumluluklar:

• Modbus, OPC UA veya saha veri yolundan MQTT'ye protokol çevirisi.
• Tutarlı birimlere ve adlara normalizasyon; böylece spindle_rpm her yerde aynı anlama gelir.
• Bir değeri yalnızca anlamlı ölçüde değiştiğinde veya sabit aralıklarla yayınlayan ölü bant (deadband) ve hız kontrolü.
• Üst bağlantı koptuğunda ara belleğe alma ve ardından veriyi orijinal zaman damgalarıyla yeniden oynatma.

Zaman damgalarını kaynakta ekleyin. Bir değerin yalnızca broker'a ne zaman ulaştığını bilen bir ikiz, yavaş bir ağı yavaş bir makineden ayırt edemez.

Katman 2: Mesajlaşma Omurgası

Mesajlaşma katmanı dijital ikiz mimarisinin belkemiğidir. Her üretici ona yayınlar ve her tüketici ondan abone olur; bu da cihazların kimin izlediğini bilmesine hiç gerek olmadığı anlamına gelir. Bir MQTT broker en yaygın tercihtir, çünkü size şunları sunar:

• Varlık hiyerarşisini yansıtan hiyerarşik topic'ler.
• Hat düzeyindeki bir görüntüleyicinin plant1/line2/# adresine abone olup her makineyi almasını sağlayan wildcard'lar.
• Yeni abonelere en son durumu hemen ileten retained mesajlar.
• Teslimat garantilerini ek yükle dengelemek için QoS seviyeleri.
• İkizin bir cihazın ne zaman kaybolduğunu bilmesi için Last Will mesajları.

İyi bir topic tasarımı, bir mesaj sınıfıyla biten ISA-95 tarzı bir hiyerarşiyi izler:

<enterprise>/<site>/<area>/<line>/<asset>/telemetry
<enterprise>/<site>/<area>/<line>/<asset>/state
<enterprise>/<site>/<area>/<line>/<asset>/cmd
<enterprise>/<site>/<area>/<line>/<asset>/cmd/ack

telemetry (retained olmayan bir akış), state (güncel değerler, retained) ve cmd (komutlar, asla retained değil) sınıflarını ayırın. Bunları karıştırmak, yeniden bağlanma sonrasında bir cihaza bayat bir komutun yeniden iletilmesi gibi ikiz hatalarının en yaygın kaynağıdır. MQTT ile dijital ikiz rehberimiz bu kalıpları daha ayrıntılı inceler.

Broker'ı kendiniz çalıştırmak; TLS sertifikalarını, kimlik doğrulamayı, ölçeklemeyi ve izlemeyi üstlenmek demektir. ConnectMQ gibi tam yönetilen bir MQTT servisi bu işi ortadan kaldırır; böylece ekip ikizin kendisine odaklanabilir.

Katman 3: Durum

Durum katmanı tek bir soruyu yanıtlar: varlığın şu anki güncel değeri nedir? Üç yaygın seçenek vardır:

1. Retained MQTT topic'leri. Her varlığın veya özelliğin retained bir mesajı vardır. Basittir, ek altyapı gerektirmez ve görüntüleyiciler bağlandıklarında tam durumu alır. Ayrıntılar retained MQTT mesajlarını dijital ikiz durumu olarak kullanma yazısında.
2. Bir ikiz servisi. Eclipse Ditto veya özel bir mikroservis gibi ayrılmış bir servis telemetriye abone olur, varlık başına bir JSON belgesi tutar ve bunu bir API üzerinden sunar.
3. Bir abone tarafından beslenen bellek içi veya anahtar-değer deposu; birçok uygulama durumu MQTT yerine API üzerinden sorguladığında faydalıdır.

Pek çok ekip için doğru cevap önce retained topic'ler, ardından sorgulara, varlık başına erişim kontrolüne veya istenen ve bildirilen (desired vs reported) durum yönetimine ihtiyaç duyulduğunda bir ikiz servisidir. Bu kalıplar için dijital ikiz durum senkronizasyonu yazısına bakın.

Katman 4: Geçmiş

Canlı durum; trendler, kök neden analizi veya makine öğrenimi için yeterli değildir. Bir geçmiş abonesi telemetri topic'lerini dinler ve bir zaman serisi veritabanına yazar. Telegraf, Node-RED veya küçük bir Python servisi gibi araçlar bu iş için normal MQTT istemcileri olarak çalışır:

import json
import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe("acme/plant1/+/+/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    point = json.loads(msg.payload)
    asset_path = msg.topic.rsplit("/", 1)[0]
    # Bunu zaman serisi veritabanınıza yapılan bir yazma işlemiyle değiştirin
    print(asset_path, point)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()

Geçmiş yazıcılarını canlı yoldan bağımsız tutun. Veritabanı yavaşsa 3D görünüm gecikmemelidir.

Katman 5: Model

Model katmanı sayıları anlama dönüştürür. En azından bir varlık kaydıdır: hangi varlıkların var olduğu, birbirleriyle nasıl ilişkili oldukları (saha hattı, hat da makineyi içerir), her birinin hangi özelliklere ve hangi birimlere sahip olduğu. Daha gelişmiş ikizler şunları ekler:

• DTDL arayüzleri veya Asset Administration Shell alt modelleri gibi resmi şemalar.
• OEE, verimlilik veya kalan faydalı ömür gibi türetilmiş değerler.
• Davranışı tahmin edip gerçeklikle karşılaştıran simülasyon veya ML modelleri.

Modeli veri akışından ayrı saklayın, sürümleyin ve topic'lerden kararlı varlık ID'leri üzerinden referans verin. Bir makine değiştirildiğinde model değişir, ancak topic sözleşmesi aynı kalabilir.

Katman 6: Görselleştirme ve Uygulamalar

En üst katman, insanların gördüğü şeydir: panolar, 3D sahneler, mobil uygulamalar ve alarm konsolları. Tarayıcı tabanlı 3D görüntüleyiciler güvenli WebSocket üzerinden doğrudan broker'a bağlanır, ilgili dala abone olur, bağlandıklarında retained durumu yükler ve ardından canlı mesajlar geldikçe animasyon yapar. MQTT.js ile bu birkaç satırdır:

import mqtt from "mqtt";

const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
  protocolVersion: 5,
});

client.on("connect", () => {
  client.subscribe("connectmq/demo/a91c/plant1/#");
});

client.on("message", (topic, payload) => {
  const assetPath = topic.split("/").slice(3, -1).join("/");
  updateSceneObject(assetPath, JSON.parse(payload.toString()));
});

function updateSceneObject(path, values) {
  console.log("update", path, values);
}

Üretimde, salt okunur görüntüleyiciler için kapsamı sınırlandırılmış kimlik bilgileri kullanın ve komut yayınlamayı istekleri doğrulayan bir backend'in arkasında tutun.

Dijital İkiz Mimarisi Kontrol Listesi

Kurulumdan önce her maddeyi doğrulayın:

1. Ayrı telemetri, durum ve komut sınıflarıyla tanımlanmış ve belgelenmiş bir topic hiyerarşisi.
2. Birimler ve kaynak zaman damgaları dahil, varlık türü başına payload şeması.
3. Bir görüntüleyicinin yüklemede ihtiyaç duyduğu her özellik için retained durum.
4. Çevrimdışı varlıkların çevrimdışı görünmesi için Last Will mesajları.
5. Canlı yoldan ayrıştırılmış geçmiş yazıcısı.
6. Sürümlenmiş ve kararlı ID'lerle anahtarlanmış varlık modeli.
7. Tesis ağının dışında her yerde TLS, cihaz veya ağ geçidi başına benzersiz kimlik bilgileri.
8. Onay mesajları ve zaman aşımları içeren komut yolu.

ConnectMQ Mimaride Nereye Oturur

ConnectMQ mesajlaşma katmanını doldurur: MQTT 3.1.1 ve 5.0, 8883'te TLS, tarayıcı görüntüleyicileri için 8084'te güvenli WebSocket, retained mesajlar ve ücretli planlarda tüketicileri ölçeklemek için paylaşımlı abonelikler sunan bir bulut MQTT broker. Ayrıca ISA-95 topic hiyerarşilerini algılar, Sparkplug B'yi çözümleyip ISA-95 topic'lerine yeniden yayınlayabilir; bu da uçtan ikize uzanan sözleşmeyi basitleştirir. Durum depoları, geçmiş veritabanları ve model servisleri, MQTT istemcisi olarak bağlanan kendi bileşenleriniz olarak kalır. ConnectMQ 3D dijital ikiz demosu, bu mimarinin görselleştirme katmanını WSS üzerinden canlı olarak çalışırken gösterir.

Dijital İkiz Mimarinizi ConnectMQ Üzerinde Başlatın

app.connectmq.com adresinden kaydolun, kredi kartı gerektirmeyen ücretsiz Serverless planı seçin, bir broker oluşturun ve otomatik üretilen kimlik bilgileriyle uç ağ geçidinizi ve ilk görüntüleyicinizi bağlayın. Tarayıcı içi istemci ve canlı topic gezgini, tek satır görselleştirme kodu yazmadan önce topic tasarımınızı doğrulamanızı sağlar.

Sık Sorulan Sorular

Bir dijital ikiz mimarisinde en önemli katman hangisidir?

Mesajlaşma ve veri sözleşmesi katmanı. Topic'ler ve payload'lar iyi tasarlanmışsa diğer her katman bağımsız olarak oluşturulabilir, değiştirilebilir veya ölçeklenebilir.

İkiz durumu için ayrı bir veritabanına ihtiyacım var mı?

Başlangıçta hayır. Retained MQTT mesajları birçok ikizin güncel durumunu tutabilir; sorgulara, varlık başına erişim kontrolüne veya istenen durum yönetimine ihtiyaç duyduğunuzda bir ikiz servisi veya depo ekleyin.

3D görüntüleyiciler doğrudan MQTT broker'a bağlanmalı mı?

Salt okunur canlı görünümler için güvenli WebSocket üzerinden bağlanmak basit ve hızlıdır. Komutları, onları doğrulayan ve denetleyen bir backend üzerinden yönlendirin.

Bir dijital ikiz mimarisi çevrimdışı cihazları nasıl ele alır?

Çevrimdışı durumunu yayınlamak için MQTT Last Will mesajlarını kullanın, kesintiler sırasında veriyi uçta ara belleğe alın ve geç gelen verinin doğru yere yerleştirilmesi için kaynak zaman damgalarını ekleyin.