Bir IIoT edge gateway, PLC'ler, sayaçlar ve sürücülerle dolu bir fabrikayı işletmenin geri kalanının kullanabileceği yapılandırılmış MQTT mesajları akışına dönüştüren cihazdır. Bu yazı, her gateway'in yaptığı dört işi (protokol dönüşümü, tamponlama, güvenlik ve edge compute) açıklıyor, bir referans mimari gösteriyor ve seçim yapmanız için pratik bir kontrol listesi sunuyor.
Endüstriyel Tesisler Neden Edge Gateway'e İhtiyaç Duyar?
Endüstriyel ekipmanlar buluta değil, aynı ağdaki diğer ekipmanlara konuşmak üzere tasarlandı. Tipik bir fabrika sahasında RS485 üzerinden Modbus RTU, Modbus TCP, OPC UA, EtherNet/IP, PROFINET ve üreticiye özel protokoller bir arada bulunur; çoğu zaman da ofis ağından ve internetten bilinçli olarak yalıtılmış ağlarda. Bu protokollerin çoğu istek-yanıt temellidir: bir client her değer için her cihazı sorgulamak zorundadır.
Bulut sistemleri, paneller ve analitik araçları ise başka bir şey bekler: tutarlı adlar ve birimlerle güvenli, dışa doğru (outbound), olay güdümlü veri. Gateway bu iki dünya arasındaki tercüman ve nöbet kulübesidir. Gateway olmadan makine verisi isteyen her uygulamanın kendi sürücülerine, OT ağına kendi ağ yoluna ve hassas kontrolcüler üzerinde kendi sorgulama yüküne ihtiyacı olurdu.
Bir IIoT Edge Gateway'in Dört Temel Görevi
1. Protokol Dönüşümü ve Veri Modelleme
Gateway, cihazları kendi yerel protokollerinde sorgular veya onlara abone olur ve veriyi MQTT üzerinden yeniden yayınlar. İyi gateway'ler register kopyalamaktan fazlasını yapar: ölçekleme, birim ve adlandırma uygular; böylece 40001 = 2351, acme/plant1/packaging/line2/filler/temperature gibi anlamlı bir topic üzerinde {"temperature_c": 23.51} haline gelir.
Bu adlandırma adımı, gateway'in bir Unified Namespace'e katkı sağladığı yerdir. Her gateway ortak bir ISA-95 tarzı hiyerarşiye (işletme, saha, alan, hat, hücre) yayın yaparsa tüketiciler veriyi hangi gateway'in veya protokolün ürettiğini bilmeden bulabilir. Belirli dönüşüm yolları Modbus TCP'den MQTT'ye ve OPC UA - MQTT gateway rehberlerinde ele alınıyor.
2. Tamponlama ve Store-and-Forward
Fabrika ağları ve WAN bağlantıları arızalanır. Broker'a ulaşılamadığı sürece veriyi düşüren bir gateway, geçmişte çoğu zaman sonradan doldurulması imkânsız boşluklar bırakır. Endüstriyel gateway'ler mesajları yerel olarak, yalnızca bellekte değil diskte kuyruğa alır ve bağlantı geri geldiğinde sırasıyla yeniden oynatır. Tasarım ayrıntıları (tampon boyutlandırma, zaman damgaları, yeniden oynatma hızı) MQTT için store-and-forward yazısında yer alıyor.
3. Güvenlik Sınırı
Gateway genellikle hem OT ağına hem de harici bir ağa dokunan tek cihazdır. Bu da onu birkaç kuralı uygulamak için doğru yer yapar:
- Yalnızca dışa doğru bağlantılar. Gateway broker'a bir TLS bağlantısı açar; internetteki hiçbir şey tesise doğru bağlantı başlatmaz.
- Kimlik bilgisi izolasyonu. Broker kimlik bilgilerini yalnızca gateway tutar. PLC'ler asla tutmaz.
- Varsayılan olarak salt okunur. Buluttan set değeri yazmak, yapılacaksa bile, tag bazında açıkça etkinleştirilmelidir.
- Ağ segmentasyonu. Aralarında yönlendirme olmayan, her bölge için bir tane olmak üzere iki ağ arayüzü ya da endüstriyel bir DMZ'ye yerleştirme.
4. Edge Compute
Bazı mantıklar makinenin yanında olmalıdır: gürültüyü filtrelemek, ortalamaları hesaplamak, eşik aşımlarını tespit etmek veya bulut erişilemezken bile çalışması gereken alarmları yürütmek. En değerli edge hesaplaması çoğu zaman aynı zamanda en basit olanıdır: bir değeri yalnızca anlamlı şekilde değiştiğinde yayınlayan ve sabit aralıklı sorgulamaya kıyasla trafiği çarpıcı biçimde azaltabilen değişimde raporlama (report by exception).
Referans Mimari
Shop floor (OT network) Edge Cloud / IT
------------------------ ----------------- ------------------
PLC (EtherNet/IP) ---\ | IIoT edge | TLS | MQTT broker |
Energy meter (Modbus) ----+----> | gateway | -----> | (8883) | --> dashboards
CNC (OPC UA / MTConnect) --/ | - drivers | outbound| | --> historian
| - modeling | only | | --> analytics
| - buffer | | |
| - RBE / rules | ------------------
-----------------
Gateway, tesis hiyerarşisini izleyen topic'lere yayın yapar. Tipik bir payload şöyle görünür:
{
"ts": "2026-10-16T08:14:03.512Z",
"values": {
"spindle_speed_rpm": 11980,
"spindle_load_pct": 41.5,
"program": "O1234",
"state": "RUNNING"
},
"quality": "GOOD",
"source": "gw-plant1-02"
}
Her mesaja bir kaynak zaman damgası, bir kalite bayrağı ve gateway kimliği eklemek, tamponlanmış verilerin yeniden oynatılmasını ve sorun gidermeyi çok daha kolaylaştırır.
IIoT Edge Gateway Seçimi: Kontrol Listesi
| Kriter | Sorulacak sorular |
|---|---|
| Protokol sürücüleri | Bugün sahanızdaki eski seri protokoller dahil her protokolü destekliyor mu? Sürücüler protokol başına mı yoksa tag başına mı lisanslanıyor? |
| MQTT client kalitesi | MQTT 3.1.1 ve 5? Özel CA ile TLS? Yapılandırılabilir QoS, retained message, Last Will, keep alive? |
| Payload seçenekleri | Düz JSON, Sparkplug B ya da ikisi birden? Topic yapısını tamamen kontrol edebiliyor musunuz? |
| Store-and-forward | Disk destekli mi? Ne kadar? Sıralı yeniden oynatma? Hız sınırlı yeniden oynatma? |
| Edge mantığı | Deadband'ler, ölçekleme, betik desteği veya özel kod için container'lar? |
| Donanım | DIN ray, geniş sıcaklık aralığı, fansız, endüstriyel güç girişi, seri portlar? |
| Yönetim | Gelen yönde güvenlik duvarı portu açmadan uzaktan yapılandırma ve firmware güncellemesi? |
| Güvenlik | Güvenli önyükleme, imzalı güncellemeler, rol tabanlı yerel erişim, ayrı ağ arayüzleri? |
| Yaşam döngüsü | Üretici cihazı ne kadar süre destekleyecek ve cihazı değiştirirseniz yapılandırmayı dışa aktarabilir misiniz? |
Yaygın Gateway Türleri
- Özel endüstriyel gateway'ler. Üreticinin yapılandırma aracıyla gelen, amaca özel DIN ray cihazları. Devreye alması hızlıdır, ancak üreticinin sağladığı protokoller ve mantıkla sınırlıdır.
- Gateway yazılımı çalıştıran endüstriyel PC'ler. Daha esnektir: ticari bir bağlantı platformu, Node-RED veya kendi container'larınızı çalıştırabilirsiniz. Daha çok BT tarzı bakım gerektirir.
- Dahili MQTT'li PLC'ler ve kontrolcüler. Birçok modern kontrolcü doğrudan MQTT yayını yapabilir. Bu bir kutuyu ortadan kaldırır, ancak ağ sorumluluklarını kontrolcüye yükler ve her tesis bundan memnun değildir.
- Mikrodenetleyici gateway'ler. Küçük dönüşümler için bir mikrodenetleyici, ESP32 Modbus RS485 - MQTT eğitiminde olduğu gibi birkaç Modbus cihazını MQTT'ye köprüleyebilir. Pilot projeler ve kritik olmayan izleme için iyidir.
Sparkplug B mi, Düz JSON mu?
Gateway'ler giderek daha fazla Sparkplug B sunuyor; bu standart bir topic namespace'i, durum farkındalığı için birth ve death sertifikaları ve kompakt Protobuf payload'ları ekler. Düz JSON'u okumak ve herhangi bir araçtan tüketmek daha kolaydır. Pek çok tesis ikisini birden kullanır: gateway'lerden Sparkplug B, tüketiciler için ise okunabilir bir ISA-95 JSON görünümü. ConnectMQ, Sparkplug B payload'larını çözümleyip ISA-95 topic'lerine yeniden yayınlayabilir; örneğin spBv1.0/factory1/DDATA/line1/cnc1 topic'ini connectmq/factory1/production/line1/cnc1/telemetry haline getirerek iki stilin tek bir broker üzerinde bir arada var olmasını sağlar. Genel tablo MQTT ile endüstriyel IoT rehberinde yer alıyor.
Devreye Almadan Önce Gateway'i Test Etmek
Bir gateway'i üretim verisine bağlamadan önce onu bir test broker'ına yönlendirin ve topic'leri, payload'ları ve yeniden bağlanma davranışını doğrulayın:
mosquitto_sub -h broker.connectmq.com -p 1883 -i gw-test-viewer-81 -t "connectmq/demo/gw-test-81/#" -v
Gateway'i genel MQTT test broker'ında connectmq/demo/gw-test-81/... altında simüle edilmiş veya hassas olmayan değerler yayınlayacak şekilde yapılandırın, ardından ağ kablosunu birkaç dakikalığına çekin ve yeniden bağladığınızda tamponlanmış mesajların sırayla geldiğini doğrulayın. Genel alanın herkes tarafından okunabildiğini unutmayın; oraya asla gerçek tesis verisi göndermeyin.
Broker'ın Yeri
Gateway sistemin yalnızca yarısıdır. Yayın yaptığı broker; TLS'i, kimlik doğrulamayı, çok sayıda eşzamanlı aboneyi ve her tag için retained durumu yönetmek zorundadır. Bu altyapıyı kendiniz çalıştırmak yama, sertifika yenileme ve izleme demektir. Tam yönetilen bir MQTT hizmeti bu yükü ortadan kaldırır; seçenekler pilot projeler için paylaşımlı serverless broker'lardan, daha katı gereksinimler için dedicated kümelere veya kendi bulut hesabınızda konuşlandırılan broker'lara kadar uzanır. Önce barındırmanın ödünleşimlerini anlamak isterseniz bulut MQTT broker seçim rehberine bakın; mantığın ne kadarının edge'de, ne kadarının bulutta kalması gerektiğine karar vermek için de IIoT'de edge computing vs bulut bilişim yazısını okuyun.
Gateway'lerinizi ConnectMQ ile Konuşturun
ConnectMQ, her gateway'e 8883 portunda bir TLS uç noktası, client ID'sine bağlı verilmiş kimlik bilgileri, canlı bir topic gezgini ve ISA-95 seviyelerine göre düzenlenmiş bir cihaz görünümü sağlar. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve ilk gateway'inizi ona yönlendirin.
Sık Sorulan Sorular
IIoT edge gateway ile router arasındaki fark nedir?
Bir router ağ paketlerini anlamadan iletir. Bir edge gateway ise endüstriyel protokolleri anlar, değerleri okur, onları anlamlı mesajlara dönüştürür ve MQTT üzerinden yayınlar.
PLC'm MQTT destekliyorsa gateway'e ihtiyacım var mı?
Her zaman değil. Çok sayıda eski cihazınız varsa, disk destekli tamponlamaya ihtiyacınız varsa veya broker kimlik bilgilerini ve internet erişimini kontrolcülerinizden uzak tutmak istiyorsanız gateway yine de işe yarar.
Gateway Sparkplug B kullanmalı mı?
Tüketen uygulamalarınız destekliyorsa ve standartlaştırılmış durum yönetimi istiyorsanız Sparkplug B kullanın. Pek çok basit aracın veriyi doğrudan okuması gerekiyorsa düz JSON kullanın; bazı tesisler ikisini birden yayınlar.
Bir gateway ne kadar veri tamponlamalı?
Tamponu, normal veri hızınızda atlatmak istediğiniz en uzun kesinti süresine göre, bir miktar pay bırakarak boyutlandırın. Değişimde raporlama hem normal trafiği hem de tampon gereksinimlerini azaltır.
