IIoT Mimarisi Katmanları: Cihaz, Edge, Broker ve Uygulama

İyi bir IIoT mimarisi endüstriyel bir sistemi dört katmana ayırır: algılayan ve kontrol eden cihazlar, çeviren ve filtreleyen edge gateway'ler, mesajları dağıtan bir broker ve veriyi kararlara dönüştüren uygulamalar. Bu referansta her katmanın neden sorumlu olduğunu, hangi tasarım kurallarının katmanları bağımsız tuttuğunu ve dördüne birden dokunan küçük bir uçtan uca örneği nasıl çalıştıracağınızı öğreneceksiniz.

Endüstriyel IoT'de Katmanlar Neden Önemlidir?

İlk IIoT projelerinin çoğu düz borular olarak kuruldu: bir betik PLC'yi okur ve tek bir panonun sorguladığı bir veritabanına yazar. Demo için işe yarar. Sonra ikinci bir tüketici veriye ihtiyaç duyar, PLC değiştirilir veya veritabanı buluta taşınır ve her değişiklik tüm zincir boyunca dalga dalga yayılır.

Katmanlı bir mimari bu dalgaları sınırlar. Her katmanın tek bir işi ve komşularıyla net bir sözleşmesi vardır. Bir PLC'yi değiştirin, yalnızca edge yapılandırması değişir. Bir analitik aracı ekleyin, yalnızca yeni bir abone ortaya çıkar. Şirket içinden buluta geçin, edge yalnızca farklı bir broker adresine bağlanır. Bu ayrışmayı mümkün kılan publish/subscribe modelidir; bu yüzden modern IIoT tasarımlarının çoğunun merkezinde bir MQTT broker bulunur.

Dört IIoT Mimarisi Katmanı

Cihaz katmanı

Burası fiziksel dünyadır: sıcaklık probları, debimetreler, PLC'ler, sürücüler, CNC kontrolörleri ve robotlar. Cihazlar veri paylaşmak için değil, deterministik kontrol için optimize edilmiştir. Birçoğu yalnızca fieldbus veya seri protokoller konuşur, bazılarının hiç iletişim arayüzü yoktur. Bu katmandaki mimari kural basittir: IT ihtiyaçlarına hizmet etmek için kontrol mantığını değiştirmeyin. Veriyi müdahale etmeden okuyun; emniyeti ve kontrolü ait oldukları yerde bırakın.

Edge katmanı

Edge hem çevirmen hem de bekçidir. Bir edge gateway PLC tag'lerini, Modbus register'larını veya sensör girişlerini okur, ortak bir biçime dönüştürür ve MQTT üzerinden yayımlar. Ayrıca bir WAN üzerinden asla taşınmaması gereken işleri yapar: gürültüyü filtrelemek, istisna bazlı raporlamak, zaman damgası ve birim eklemek ve uplink kapalıyken veriyi tamponlamak. IIoT edge gateway seçimi ve IIoT'de edge computing ile cloud computing rehberlerimiz buraya nelerin ait olduğunu daha ayrıntılı ele alıyor.

Edge'in temel sorumlulukları:

1. Cihaz protokollerinden MQTT'ye protokol dönüşümü.
2. Adların, birimlerin ve zaman damgalarının normalleştirilmesi.
3. Trafiği azaltmak için deadband ile istisna bazlı raporlama.
4. Ağ kesintilerinde store and forward (sakla ve ilet).
5. Broker'a TLS üzerinden yalnızca dışa doğru bağlantılar.
6. Kendi sağlık bilgisini yayımlama: last will ile çevrim içi durumu, firmware, son okuma zamanı.

Broker katmanı

Broker merkezdir. Her edge gateway ona yayın yapar, her uygulama ondan abone olur. İki taraf da birbirinden habersizdir ve asıl amaç da budur. Yönlendirmenin ötesinde broker, yeni uygulamaların güncel durumu hemen görmesi için retained message'ları tutar, yeniden bağlanan client'ların oturumlarını saklar, kimlik doğrulama ve kotaları uygular ve gateway'ler koptuğunda last will mesajlarını yayımlar. Temelleri öğrenmek istiyorsanız bir MQTT broker'ın ne yaptığını okuyun.

Namespace de broker'da yaşar. Bir Unified Namespace topic'leri ISA-95 hiyerarşisine göre düzenler; örneğin connectmq/acme/plant1/packaging/line4/filler02/telemetry. Böylece her uygulama veriyi tag listesine göre değil konuma göre bulabilir. Bu ağacı tasarlamanın kuralları UNS topic yapısı rehberimizde yer alıyor.

Uygulama katmanı

Uygulamalar verinin değere dönüştüğü yerdir: canlı panolar, OEE hesaplamaları, alarm bildirimleri, historian'lar, MES ve ERP entegrasyonu, makine öğrenimi. Her uygulama yalnızca bir başka MQTT client'ıdır. Namespace'in ihtiyaç duyduğu kısmına abone olur ve hesaplanmış bir OEE veya öngörülen bir arıza gibi sonuçları geri yayımlayabilir; diğer uygulamalar da bunları tüketebilir. Uzun süreli depolama genellikle bir zaman serisi veritabanına yazan özel bir abonedir; bu konu MQTT historian yazımızda ele alınıyor.

Mimariyi Temiz Tutan Tasarım Kuralları

1. Her ok broker'ı gösterir. Cihazlar asla doğrudan uygulamalarla konuşmaz, uygulamalar da asla cihazları sorgulamaz.
2. Bağlantılar dışa doğrudur. Edge ve uygulamalar broker'a bağlantı açar; hiçbir şey tesise bağlantı açmaz.
3. Tek bir namespace, belgelenmiş. Topic hiyerarşisi ve payload biçimi yazılı ve sürümlüdür.
4. Durumu retain edin, olayları etmeyin. Güncel değerler retained'dır; alarmlar ve parça tamamlamaları değildir.
5. Her client'ın kendi kimliği vardır. Gateway ve uygulama başına ayrı kimlik bilgileri; böylece biri diğerlerini etkilemeden iptal edilebilir.
6. Zekâ doğru katmanda. Zaman açısından kritik mantık cihazda veya edge'de kalır; sahalar arası analitik uygulama katmanına aittir.
7. Sistemin kendisini gözlemleyin. Gateway durumu, bağlantı durumu ve mesaj hızları da veridir.

Dört Katmanın Tamamını Kapsayan Uçtan Uca Örnek

Aşağıdaki örnek public test broker'ı kullanır. Bash komutu, cihaz okumalarını yayımlayan edge katmanını canlandırır. Python betiği bir uygulamadır: her okumayı SQLite'ta saklayan ve bir eşik aşıldığında uyarı yayımlayan küçük bir historian.

Edge katmanı (simüle), her iki saniyede bir okuma yayımlar:

ID=arch-$RANDOM
echo "Use prefix connectmq/demo/$ID"
while true; do
  T=$(awk -v r=$RANDOM 'BEGIN{printf "%.1f", 60 + (r % 300) / 10}')
  mosquitto_pub -h broker.connectmq.com -p 1883 -i "$ID-edge" -q 1 \
    -t "connectmq/demo/$ID/plant1/heat/furnace1/temperature" \
    -m "{\"value\":$T,\"unit\":\"C\"}"
  sleep 2
done

Uygulama katmanı, veriyi saklar ve uyarı yayımlar:

import json
import sqlite3
import sys
import time
import paho.mqtt.client as mqtt

PREFIX = sys.argv[1]  # örn. connectmq/demo/arch-12345
LIMIT_C = 85.0

db = sqlite3.connect("historian.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS readings (ts REAL, topic TEXT, value REAL)")

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{PREFIX}/plant1/+/+/temperature", qos=1)

def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    value = float(data["value"])
    db.execute("INSERT INTO readings VALUES (?, ?, ?)", (time.time(), msg.topic, value))
    db.commit()
    print(f"{msg.topic} = {value}")
    if value > LIMIT_C:
        alert_topic = msg.topic.rsplit("/", 1)[0] + "/alert"
        client.publish(alert_topic, json.dumps({"reason": "over_limit", "value": value}), qos=1)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"{PREFIX.split('/')[-1]}-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Betiği edge döngüsünün yazdırdığı önekle çalıştırın; örneğin python historian.py connectmq/demo/arch-12345. Asla olmayan şeye dikkat edin: historian fırının IP adresini bilmez, edge döngüsü de historian'ın var olduğunu bilmez. İkisine de dokunmadan ek aboneler olarak bir pano, ikinci bir historian veya bir ML modeli ekleyebilirsiniz. Üretimde iki tarafı da TLS ile 8883 portuna ve portaldaki ConnectMQ kimlik bilgilerine taşıyın; gerçek tesis verisini herkesin okuyabildiği public broker'dan uzak tutun.

Broker'ın Nerede Çalışacağını Seçmek

Broker katmanı şirket içinde, bir DMZ'de, bulutta veya bunların bir kombinasyonunda çalışabilir. Katı izolasyona sahip tek bir tesis yerel bir broker tutabilir. Çok sahalı kuruluşlar genellikle tüm sahaların dışa doğru ulaştığı merkezi bir broker ister. Broker'ı kendiniz çalıştırmak yama, sertifika yenileme, izleme ve kapasite planlaması demektir. Yönetilen bir MQTT broker bu işi ortadan kaldırır; bulut MQTT broker rehberimiz de barındırma modellerini karşılaştırıyor.

ConnectMQ bu mimarideki broker katmanı olacak şekilde tasarlanmıştır. TCP 1883, TLS 8883, WebSocket 8083 ve güvenli WebSocket 8084 üzerinden MQTT 3.1.1 ve 5.0'ı destekler; böylece edge gateway'ler ve tarayıcı uygulamaları aynı namespace'e bağlanır. ISA-95 ve Unified Namespace topic'lerini algılar, Sparkplug B'yi çözüp ISA-95 topic'lerine yeniden yayımlar; ISA-95 seviyesine göre bir cihaz görünümü, canlı bir topic explorer ve eşik uyarı kuralları sunar. Historian'lar, veritabanları ve panolarla entegrasyonlar yukarıdaki modeli izler: Node-RED, Telegraf veya kendi aboneleriniz gibi araçlar ConnectMQ'ya MQTT client'ı olarak bağlanır. Dağıtım seçenekleri ücretsiz Serverless'tan Dedicated kümelere ve kendi bulut hesabınızda BYOC'ye kadar uzanır. Endüstriyel resmin tamamı için MQTT ile Endüstriyel IoT rehberini okuyun.

ConnectMQ ile Başlayın

app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun. Bir edge gateway'i ve bir uygulamayı ona yönlendirin; IIoT mimarinizin dört katmanının tamamı bir öğleden sonra içinde çalışır hâle gelsin.

Sık Sorulan Sorular

Bir IIoT mimarisinin katmanları nelerdir?

Pratik bir referans dört katman kullanır: algılayan ve kontrol eden cihazlar, veriyi toplayıp dönüştüren edge gateway'ler, mesajları yönlendirip durumu tutan bir broker ve görselleştiren, saklayan ve analiz eden uygulamalar.

IIoT mesajlaşma katmanı olarak neden MQTT kullanılır?

MQTT hafiftir, olay güdümlüdür ve dışa doğru bağlantılar kullanır; bu yüzden segmentli tesis ağlarında iyi çalışır. Publish/subscribe modeli, birçok uygulamanın noktadan noktaya entegrasyonlar olmadan aynı veriyi kullanmasını sağlar.

İşleme edge'de mi yoksa bulutta mı yapılmalı?

Zaman açısından kritik filtreleme, protokol dönüşümü ve tamponlama edge'e aittir. Makineler ve sahalar arası analitik, uzun süreli depolama ve iş entegrasyonu genellikle uygulama katmanına, çoğu zaman da buluta aittir.

Purdue modeli bu IIoT mimarisiyle nasıl ilişkilidir?

Purdue modeli ağ güvenliği seviyelerini, bu mimari ise veri akışını tanımlar. Birbirlerini tamamlarlar: cihazlar alt Purdue seviyelerinde, edge gateway'ler saha seviyesinde, broker ise DMZ'de veya bulutta yer alır.