IIoT veri modelleme, binlerce şifreli PLC etiketini, yanında bir etiket tablosuna ihtiyaç duymadan her uygulamanın tüketebileceği yapılandırılmış ve kendini tanımlayan bilgiye dönüştürme işidir. Bu rehberde iyi bir endüstriyel veri modelinin üç katmanını, ISA-95, Sparkplug B şablonları ve OPC UA'nın birbirini nasıl tamamladığını ve modellenmiş bir varlığı MQTT üzerinden nasıl yayınlayacağınızı öğreneceksiniz; sonucu da dakikalar içinde görebilir ve test edebilirsiniz.
Düz Etiketler Neden Ölçeklenmez?
Her tesis etiketlerle başlar. Bir PLC N7:42, DB10.DBW4 veya Line2_Mtr3_Amps gibi etiketler sunar ve birileri her birinin ne anlama geldiğini açıklayan bir tablo tutar. Bu, tek bir kontrolörle konuşan tek bir HMI için işe yarar. İkinci bir tüketici eklediğiniz anda çöker.
Sorunlar öngörülebilir biçimlerde ortaya çıkar:
- Anlam verinin dışında yaşar.
T_204etiketi yalnızca bir belge öyle dediği için sıcaklıktır. Birim, geçerli aralık ve ait olduğu varlık payload'da yer almaz. - Her entegrasyon eşlemeyi tekrarlar. MES ekibi, historian ekibi ve analitik ekibi aynı etiket sözlüğünü ayrı ayrı yeniden kurar ve her sürüm zamanla birbirinden uzaklaşır.
- Aynı makineler farklı görünür. Üç tedarikçiden gelen beş dolum makinesi beş farklı adlandırma şeması sunar; bu yüzden biri için hazırlanmış bir pano diğerleri için yeniden kullanılamaz.
- Değişiklikler tüketicileri sessizce bozar. Bir kontrol mühendisi bir etiketi yeniden adlandırdığında, aşağı akıştaki uygulamalara hiçbir şey haber vermez.
Bir veri modeli; yapıyı, bağlamı ve kimliği verinin kendisine yerleştirerek bunu çözer. Bir unified namespace yapısının temelidir ve bir tesisin verisini yalnızca erişilebilir değil, yeniden kullanılabilir kılan şeydir.
Bir IIoT Veri Modelinin Üç Katmanı
IIoT veri modellemeyi düşünmenin faydalı bir yolu üç katmandır. Her biri farklı bir soruyu yanıtlar ve her biri bağımsız olarak tasarlanabilir.
| Katman | Yanıtladığı soru | Tipik standart veya araç | Örnek |
|---|---|---|---|
| Konum (nerede) | Bu hangi sahaya, alana, hatta ve hücreye ait? | ISA-95 ekipman hiyerarşisi | acme/berlin/packaging/line2/filler1 |
| Tip (ne) | Bu ne tür bir varlık ve her zaman hangi özniteliklere sahip? | Sparkplug B şablonları, OPC UA ObjectType'ları | Hız, durum, sayaç ve hurdalarıyla Filler |
| Örnek verisi (değer) | Güncel değer ne; hangi birim, kalite ve zaman damgasıyla? | Payload şeması (JSON veya Protobuf) | {"value": 118.4, "unit": "bpm", "ts": ...} |
Konum: ISA-95 yolu
Konum katmanı, her veri noktasına insanların tanıdığı bir adres verir. ISA-95; kuruluş, saha, alan, üretim hattı veya iş merkezi ve iş biriminden oluşan bir hiyerarşi tanımlar. Bunu topic yolu olarak kullanmak, bir değerin adresinin size onun fiziksel olarak nereden geldiğini de söylemesi anlamına gelir. ISA-95 ekipman hiyerarşisi yazısı seviyelerin seçimine daha derinlemesine giriyor; ISA-95 MQTT topic'leri ise bunların topic seviyelerine nasıl eşlendiğini gösteriyor.
Konum katmanını kalıcı tutun. Fiziksel yerleşim nadiren değişir; bu yüzden iyi bir omurgadır. Ürün kodları veya vardiya adları gibi değişken şeyleri yola koymaktan kaçının.
Tip: yeniden kullanılabilir varlık tanımları
Asıl modelleme tip katmanında gerçekleşir. Bir Pump tipini öznitelikleri (debi, çıkış basıncı, motor akımı, çalışma durumu), birimleri ve izin verilen aralıklarıyla bir kez tanımlarsınız; altında hangi PLC veya tedarikçi olursa olsun her pompa örneği bu tanımı izler.
Endüstriyel MQTT sistemlerinde tipleri ifade etmenin iki yaygın yolu vardır:
- Sparkplug B şablonları, bir edge node'un birth certificate içinde bir şablon tanımı yayınlamasına ve ardından ona referans veren örnekler yayınlamasına olanak tanır. İşleyiş için Sparkplug şablonları rehberine bakın.
- OPC UA ObjectType'ları ve companion spesifikasyonları, pek çok makine sınıfı için zengin, standartlaştırılmış tipler tanımlar. Makineleriniz zaten OPC UA konuşuyorsa yeni tipler icat etmek yerine bunları yeniden kullanın. OPC UA ve MQTT karşılaştırması ikisinin nasıl bir arada var olduğunu açıklıyor.
Hiçbiri uygun değilse, sürüm kontrolünde saklanan, varlık tipi başına basit bir JSON Schema başlamak için yeterlidir.
Örnek verisi: tutarlı bir payload
Değer katmanı payload'dur. Hangi formatı seçerseniz seçin, her değer aynı zarfı taşımalıdır: değer, mühendislik birimi, kaynaktan gelen zaman damgası ve bir kalite göstergesi. Kaynak zaman damgası olmadan tüketiciler geç gelen bir mesajı yeni bir okumadan ayırt edemez. Kalite bilgisi olmadan donmuş bir sensör kararlı bir proses gibi görünür.
Adım Adım Bir IIoT Veri Modeli Tasarlamak
Aşağıdaki kontrol listesi ilk hat veya ilk makine sınıfı için işe yarar. Herhangi bir gateway yapılandırması yazmadan önce kâğıt üzerinde yapın.
- Birden fazla örneği olan tek bir varlık sınıfı seçin. Pompalar, motorlar veya dolum makineleri iyi adaylardır, çünkü yeniden kullanım hemen karşılığını verir.
- Tüketicilerin sorduğu soruları listeleyin. "Çalışıyor mu?", "Bu saat ne kadar üretti?", "Arızaya doğru kayıyor mu?" Model bu soruları doğrudan yanıtlamalıdır.
- Tipi tanımlayın. Her özniteliği sade bir dille adlandırın; bir birim, bir veri tipi ve beklenen bir aralık atayın. Hangi özniteliklerin telemetri (sık değişir), durum (olaylarla değişir) ve metadata (nadiren değişir) olduğuna karar verin.
- Etiketleri tedarikçi bazında özniteliklere eşleyin. Tedarikçiye özgü etiket adlarının görünmesi gereken tek yer burasıdır; genellikle edge gateway.
- Konum yolunu sabitleyin. İhtiyaç duyduğunuz ISA-95 seviyelerini seçin ve her seviye için izin verilen adları yazın.
- Payload zarfını seçin. Değer, birim, zaman damgası ve kalite içeren JSON, hata ayıklaması en kolay olanıdır. Sparkplug B Protobuf daha kompakttır ve birth ile death semantiğini taşır.
- Modeli sürümleyin. Tüketicilerin değişiklikleri algılayabilmesi için bir
modelVersionözniteliği ekleyin veya tip tanımlarını bir depoda tutun. - Tek bir örnek yayınlayın ve tüketicilerle birlikte gözden geçirin; ardından filonun geri kalanına yaygınlaştırın.
Modellenmiş Bir Varlığı MQTT Üzerinden Yayınlamak
İşte modellenmiş bir dolum makinesi yayınlayan minimal bir Python örneği: metadata retained message olarak, telemetri periyodik mesajlar olarak ve hepsi bir ISA-95 yolu altında. Örnek, broker.connectmq.com adresindeki ücretsiz herkese açık MQTT test broker'ını kullanır; bu yüzden ona gerçek tesis verisi göndermeyin, herkese açık alan herkes tarafından okunabilir.
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/berlin/line2/filler1"
# Tip tanımı: her Filler'ın nasıl göründüğü
FILLER_MODEL = {
"type": "Filler",
"modelVersion": "1.2.0",
"attributes": {
"speed": {"unit": "bpm", "dataType": "float", "min": 0, "max": 200},
"state": {"dataType": "string", "enum": ["RUNNING", "IDLE", "FAULT"]},
"goodCount": {"unit": "units", "dataType": "int"},
"rejectCount": {"unit": "units", "dataType": "int"},
},
"metadata": {"vendor": "ExampleVendor", "serial": "F-2291", "commissioned": "2024-03-11"},
}
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"model-demo-{RUN_ID}")
client.on_connect = on_connect
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()
# Geç gelen abonelerin keşfedebilmesi için modeli bir kez, retained olarak yayınla
client.publish(f"{BASE}/model", json.dumps(FILLER_MODEL), qos=1, retain=True)
good, rejects = 0, 0
try:
while True:
ts = int(time.time() * 1000)
speed = round(random.gauss(120, 4), 1)
good += int(speed / 60 * 5)
rejects += 1 if random.random() < 0.05 else 0
for name, value, unit in [
("speed", speed, "bpm"),
("goodCount", good, "units"),
("rejectCount", rejects, "units"),
]:
payload = {"value": value, "unit": unit, "ts": ts, "quality": "GOOD"}
client.publish(f"{BASE}/telemetry/{name}", json.dumps(payload), qos=0)
client.publish(f"{BASE}/state", json.dumps({"value": "RUNNING", "ts": ts}), qos=1, retain=True)
time.sleep(5)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Sonucu Mosquitto istemcisiyle izleyin:
mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM -t "connectmq/demo/+/berlin/#" -v
Derinliğe dikkat edin: herkese açık broker en fazla 8 topic seviyesine izin verir; bu yüzden demo, demo önekinin altında yalnızca saha, hat ve makineyi tutar (en derin topic olan .../filler1/telemetry/speed tam olarak 8 seviyedir). Kendi namespace'inizde kuruluş ve alanı da eklersiniz. Üretimde bir yönetilen MQTT broker üzerinde kendi kimlik bilgilerinizi kullanırsınız ve paylaşılan bir demo önekiyle sınırlı kalmazsınız.
ConnectMQ Modeli Görmenize Nasıl Yardımcı Olur?
Modellenmiş veri akmaya başladığında onu doğrulamanın bir yoluna ihtiyacınız olur. ConnectMQ, ISA-95 ve Unified Namespace tarzı topic'leri algılar ve bağlı cihazları portalda ISA-95 seviyelerine göre gruplanmış olarak gösterir; böylece yanlış bir seviye veya hatalı yazılmış bir hat adı hemen göze çarpar. Canlı topic gezgini retained model ve durum mesajlarını telemetrinin yanında gösterir; bu da zarfın örnekler arasında tutarlı olduğunu doğrulamanın hızlı bir yoludur.
Edge node'larınız Sparkplug B yayınlıyorsa ConnectMQ Protobuf payload'ları çözer ve bunları ISA-95 topic'lerine yeniden yayınlayabilir; örneğin spBv1.0/factory1/DDATA/line1/cnc1, connectmq/factory1/production/line1/cnc1/telemetry olur. Bu size sahadan kompakt Sparkplug taşıması, tüketiciler için ise okunabilir, modellenmiş topic'ler sağlar. Sparkplug B ve unified namespace yazısı bu deseni ayrıntılı olarak ele alıyor.
IIoT Veri Modellemede Yaygın Tuzaklar
- Prosesi değil, PLC'yi modellemek. Özniteliğinizin adı
DB10_Word4ise yalnızca etiketi taşımış olursunuz. Operatörlerin ve mühendislerin konuştuğu şeyi modelleyin. - Çok fazla hiyerarşi seviyesi. Her ek seviye, adlandırma tutarsızlığı için bir fırsattır. Tesisinizde gerçekten farklılaşan seviyeleri kullanın, gerisini atlayın.
- Öznitelik adlarında birim.
temperature_degC, adı birime bağlar. Birimi payload'a veya tip tanımına koyun. - Kaynak zaman damgası yok. Broker'a varış zamanı ölçüm zamanı değildir; özellikle gateway'ler kesintiler sırasında tamponlama yaptığında.
- Durum ve telemetriyi tek akışta karıştırmak. Durum değişiklikleri nadirdir ve retained olmalıdır; yüksek frekanslı telemetri genellikle olmamalıdır.
- Sahiplik yok. Sahibi olmayan bir model zamanla dağılır. Her varlık tipi için bir kişi veya ekip atayın.
Model Bundan Sonra Nereye Gider?
İyi bir veri modeli kendi başına bir amaç değildir. Historian'ı, MES'i, panoları ve makine öğrenmesini besler. MQTT ile endüstriyel IoT rehberi daha geniş mimariyi gösteriyor; mesajların tüm bu tüketiciler arasında nasıl yönlendirildiğini anlamak istiyorsanız bir MQTT broker'ın ne yaptığı ile başlayın. Tek bir tesisin ötesine geçtiğinizde bir bulut MQTT broker, birden fazla sahanın tek ve tutarlı bir namespace'e yayın yapmasını sağlar.
ConnectMQ ile Başlayın
Bir varlık sınıfını modelleyin, yayınlayın ve gerçek bir broker'da inceleyin. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, ardından gateway'inizi veya yukarıdaki Python betiğini kendi kimlik bilgilerinize (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID) yönlendirin ve hiyerarşinizin tasarladığınız gibi görünüp görünmediğini ISA-95 cihazlar görünümüyle kontrol edin.
Sık Sorulan Sorular
IIoT veri modelleme nedir?
IIoT veri modelleme, endüstriyel veriye tutarlı bir yapı kazandırma pratiğidir: bir varlık hiyerarşisinde bir konum, bir varlığın hangi özniteliklere sahip olduğunu tanımlayan bir tip ve birim, zaman damgası ve kalite içeren bir payload formatı. Etiket tablolarının yerini kendini tanımlayan veriyle değiştirir.
Sparkplug B şablonlarını mı yoksa OPC UA tiplerini mi kullanmalıyım?
Makineleriniz zaten OPC UA tipleri sunuyorsa veya ekipman sınıfınız için bir companion spesifikasyonu mevcutsa OPC UA tiplerini kullanın. Edge mimariniz MQTT'ye özgüyse ve birth ile death semantiği istiyorsanız Sparkplug B şablonlarını kullanın; ikisi de aynı ISA-95 namespace'ini besleyebilir.
Etiketten modele eşleme nerede yapılmalı?
PLC'ye en yakın edge gateway'de veya bağlayıcıda. Bu, tedarikçiye özgü adları tek bir yerde tutar ve gateway'in üzerindeki her tüketicinin yalnızca temiz modeli görmesini sağlar.
Unified namespace'e başlamadan önce bir veri modeline ihtiyacım var mı?
En azından konum katmanına ve bir payload zarfına ihtiyacınız var. Varlık tipleri sınıf sınıf eklenebilir; ancak önce yollar ve zarf üzerinde uzlaşmak, ileride maliyetli yeniden adlandırmaları önler.
