Edge Gateway Seçimi: Protokol Sürücüleri, Tamponlama ve Yönetim

Historian’da açıklanamayan boşluklar, vardiya sonunda tutmayan sayaçlar, IT ağından PLC’ye ping atılabildiğinin fark edilmesi. Veri toplama projelerinde bu sorunların izini sürdüğümüzde çoğu zaman aynı noktaya varıyoruz: yanlış seçilmiş ya da yanlış yapılandırılmış bir edge gateway. Gateway sahadaki farklı protokolleri okur, veriyi anlamlı isimlere ve birimlere çevirir, bağlantı koptuğunda tamponlar ve OT ağı ile üst katmanlar arasında kontrollü bir geçiş noktası olur. Aşağıda seçimde bakılacak teknik kriterleri, karar tablolarını ve bir tamponlama hesabını sırayla veriyoruz.

Gateway mimaride hangi işi yapacak

“Edge gateway” piyasada çok farklı ürünlere verilen bir isim: basit bir Modbus RTU–TCP dönüştürücüden konteyner çalıştıran endüstriyel bilgisayara kadar. Katalog açmadan önce gateway’in sizin mimarinizde hangi görevleri üstleneceğini yazın:

• Toplama: PLC, sürücü, enerji analizörü gibi kaynaklardan veriyi okumak (polling) veya aboneliklerle almak.
• Normalleştirme: Ham adresleri (DB12.DBW40, 40001) anlamlı isimlere, birimlere ve ölçeklenmiş değerlere çevirmek.
• Ön işleme: Deadband, değişimde gönderme, basit hesaplamalar (sayaç farkı, durum türetme).
• Tamponlama: Merkezle bağlantı koptuğunda veriyi saklayıp sonra sırasıyla göndermek.
• Yayımlama: Veriyi OPC UA sunucusu, MQTT/Sparkplug B veya doğrudan historian’a yazma yoluyla sunmak.
• Ağ sınırı: OT ağı ile üst ağ arasında yönlendirme yapmadan yalnız uygulama düzeyinde veri aktarmak.

İhtiyaç yalnız seri–Ethernet dönüşümüyse basit bir protokol dönüştürücü yeter; o senaryoyu Modbus RTU’dan Modbus TCP’ye geçiş yazısında anlattık. Burada odak, yukarıdaki görevlerin çoğunu üstlenen veri toplama gateway’leri.

Protokol sürücüsü ve PLC uyumluluğu

İlk eleme kriteri, sahadaki cihazları güvenilir şekilde okuyabilmesidir. Envanteri model ve firmware düzeyinde çıkarın. “Siemens desteklenir” cümlesi tek başına bir şey söylemez: S7-300/400’ün klasik S7 erişimini mi, S7-1200/1500’de PUT/GET izni ve optimize edilmemiş bloklar gerektiren erişimi mi, yoksa yalnız PLC’nin OPC UA sunucusu üzerinden erişimi mi kastediyor? Satıcıya yazılı sorun.

Kontrol edilecek	Neden önemli
PLC ailesi ve erişim yöntemi	Aynı üreticinin farklı serileri farklı sürücü ve PLC ayarı gerektirir
Sürücü kaynağı	Üreticinin kendi sürücüsü mü, lisanslı üçüncü taraf mı, açık kaynak mı; destek ve güncelleme buna bağlı
Okuma optimizasyonu	Ardışık adresleri blok halinde okuyabilmek PLC yükünü ve çevrim süresini belirler
Bağlantı sayısı	PLC’nin eşzamanlı bağlantı kapasitesi sınırlıdır; gateway kaç bağlantı açıyor?
Sürücü başına lisans	Bazı ürünlerde sürücü veya tag sayısı ayrı lisanslanır; toplam maliyeti değiştirir
Kuzey yönlü protokoller	OPC UA sunucusu, MQTT, Sparkplug B, REST, veritabanı yazma desteği

S7 serilerinde hangi erişim yönteminin hangi PLC ayarını gerektirdiğini ve güvenliğe etkisini S7 PLC veri okuma yöntemleri yazısında karşılaştırdık. Satın almadan önce en az bir pilot PLC üzerinde, gerçek tag listesiyle ve hedeflenen okuma aralığında test yapın. Katalogdaki sürücü listesi, sahadaki firmware sürümüyle uyumluluğu garanti etmez. Pilot yapılmadan alınan gateway, devreye almada sürpriz çıkarır.

Store-and-forward ve bağlantı kesintisi

Bağlantı kesintisi istisna değildir; planlanır. Merkez sunucu bakımı, WAN kesintisi, broker güncellemesi, DMZ firewall değişikliği. Gateway bu sürede veriyi diske yazmalı, bağlantı geri geldiğinde sırasıyla ve orijinal zaman damgalarıyla göndermeli. Satıcıya sorulacaklar:

• Tampon bellekte mi, kalıcı depolamada mı? Elektrik kesintisinde tampon kayboluyor mu?
• Kapasite dolunca en eski veri mi siliniyor, yeni veri mi reddediliyor? Bu davranış yapılandırılabiliyor mu?
• Bağlantı geri geldiğinde geçmiş veri ile canlı veri nasıl ayrılıyor? (Sparkplug B’de is_historical bayrağı bu iş içindir; ayrıntılar MQTT Sparkplug B rehberinde.)
• Geri gönderim hızı sınırlanabiliyor mu? Bir hafta sonu biriken verinin tamamı aynı anda merkeze basılırsa historian’ı ve broker’ı zorlar.

Örnek hesap: Gateway 2.000 tag okuyor, her tag ortalama 10 saniyede bir değişiyor ve değişimde kaydediliyor. Saniyede ortalama 200 değer oluşur. Değer başına (tag kimliği, zaman damgası, değer, kalite) 32 bayt varsayılırsa günlük veri hacmi:

200 değer/s × 32 bayt × 86.400 s ≈ 553 MB/gün
7 günlük kesinti hedefi        ≈ 3,9 GB
İndeks/biçim ek yükü için ×2   ≈ 8 GB tampon alanı

Gerçek değerler ürüne ve depolama biçimine göre değişir; hesabın amacı hangi büyüklük sırasında depolama gerektiğini görmektir. Değişim sıklığını tahmin etmeyin, pilot süresince ölçün. Kesinti hedefini (bir vardiya mı, bir hafta sonu mu) operasyon ekibiyle birlikte belirleyin. Sürekli yazma yapılacağı için depolama endüstriyel sınıf olmalı ve yazma dayanıklılığı (TBW) veri sayfasında belirtilmeli. Tüketici sınıfı SD kartlar bu iş yükünde erken arızalanabilir. Sahada en sık değiştirdiğimiz parça budur.

Donanım seçenekleri

Seçenek	Avantaj	Sınırlama	Uygun senaryo
Kutu gateway (hazır yazılım)	Hızlı devreye alma, web arayüzü, düşük güç	Sürücü ve özelleştirme ürünle sınırlı	Hat veya makine başına standart toplama
Endüstriyel PC (fansız)	Esnek yazılım, konteyner, yüksek işlem gücü	İşletim sistemi bakımı ve güvenlik sıkılaştırması size kalır	Alan seviyesi toplama, yerel hesaplama, çok sürücü
PLC ek modülü / PLC tabanlı edge	PLC’ye yakın, üretici desteği, rack içinde	Üretici ekosistemine bağlılık, sınırlı kaynak	Tek üreticili hatlar, makine üreticisi entegrasyonu
Sanallaştırılmış edge (sunucu üzerinde)	Merkezi yönetim, yüksek kaynak	Saha ile arasında ağ bağımlılığı; donanım OT dolabında değil	Kontrol odasında sunucu altyapısı olan tesisler

Fiziksel koşullar en sık atlanan kısımdır. Panoya girecek gateway için kontrol edin: DIN rayına montaj, 24 V DC besleme ve yedekli besleme girişi, çalışma sıcaklığı aralığı, fansız tasarım, toz ve titreşim koşullarına uygunluk, ilgili EMC ve gerekiyorsa tehlikeli bölge sertifikaları. Pano içi sıcaklığı kışın değil, yaz aylarında ölçün. Ofis tipi mini bilgisayarlar pano içinde kısa sürede ısıl sorun yaşar. Pano, ofis değildir.

Ağ konumu ve çift arayüz tasarımı

Veri toplama gateway’leri çoğunlukla iki ağ arayüzüyle kurulur: biri hücre veya alan ağına (güney), diğeri üst katmana veya DMZ’ye (kuzey) bakar. Bu tasarımın güvenlik değeri tek bir şarta bağlıdır: gateway iki ağ arasında yönlendirme yapmamalı. Veriyi yalnız uygulama düzeyinde okuyup yayımlamalı; IT tarafından gelen bir paket hiçbir koşulda PLC ağına geçmemeli. Sahada en sık gördüğümüz hata, varsayılan imajda açık bırakılmış IP yönlendirmesidir. İki bacaklı gateway, yönlendirme açıksa router’dır.

Linux tabanlı bir gateway’de bunu doğrulamak ve sabitlemek için:

# IP yönlendirme kapalı olmalı (0)
sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
printf "net.ipv4.ip_forward = 0\nnet.ipv6.conf.all.forwarding = 0\n" | sudo tee /etc/sysctl.d/99-edge.conf
sudo sysctl --system

# /etc/nftables.conf (örnek): forward zinciri kapalı,
# yönetim erişimi yalnız tanımlı istasyondan
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    iifname "eth1" ip saddr 10.20.0.10 tcp dport 22 accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
}

Örnekte eth1 kuzey arayüzü, 10.20.0.10 yönetim istasyonudur; giden MQTT/OPC UA bağlantıları established kuralıyla yanıt alır. Gateway SCADA gibi istemcilere OPC UA sunucusu olarak da hizmet verecekse, ilgili porta (varsayılan TCP 4840) yalnız o istemcilerin adreslerinden izin veren ayrı bir kural ekleyin. Parametrenin anlamı Linux çekirdeği ip-sysctl dokümantasyonunda açıklanır. Kutu gateway’lerde aynı davranışı (yönlendirme/NAT kapalı) ürün ayarlarında doğrulayın; menüde göremiyorsanız iki ağ arasında test paketiyle deneyin.

Bağlantı yönü de bir karardır. Gateway’in kuzeydeki broker’a veya historian’a kendisinin bağlanması (giden bağlantı), üst ağdan gateway’e gelen bağlantılara izin vermekten daha kolay denetlenir. DMZ’de mi, alan ağında mı duracağı tesisin zon yapısına bağlıdır; seçenekleri OT DMZ tasarımı yazısında karşılaştırdık.

Uzaktan yönetim, güncelleme ve yedekleme

Otuz gateway’i tek tek web arayüzünden yönetmeye kalkarsanız bir yıl sonra otuz farklı yapılandırmanız ve unutulmuş güncellemeleriniz olur. Değerlendirilecek yönetim özellikleri:

• Merkezi yönetim: Yapılandırma, sürücü ve tag listesi merkezden dağıtılmalı; CPU, disk, tampon doluluğu ve sürücü hataları gibi sağlık verileri izlenebilmeli.
• Güvenli güncelleme: İmzalı firmware, başarısız güncellemede önceki sürüme dönüş (A/B bölümleme gibi), güncellemenin planlı pencerede yapılabilmesi.
• Yapılandırma yedeği: Dışa aktarılabilir, sürüm kontrolüne alınabilir metin tabanlı yapılandırma. Hedef: arızalı cihazın yerine yenisini takıp yapılandırmayı yükleyerek dakikalar içinde devreye almak.
• Kimlik ve erişim: Varsayılan parolanın ilk açılışta değişmesi, rol tabanlı yetki, mümkünse merkezi kimlik doğrulama; yönetim erişimi yalnız yönetim ağından.
• Güvenlik özellikleri: Güvenli önyükleme, TPM, kullanılmayan servislerin kapatılabilmesi, günlüklerin merkezi sisteme (syslog) gönderilmesi.
• Yaşam döngüsü: Üreticinin güvenlik güncellemesi sağlama süresi ve zafiyet bildirim süreci. Destek süresini üreticinin güncel yaşam döngüsü sayfasından doğrulayın.

Seçim kontrol listesi

• Sahadaki tüm PLC ve cihazlar model/firmware düzeyinde listelendi; her biri için sürücü ve erişim yöntemi pilotla doğrulandı.
• Gerekli kuzey yönlü protokoller (OPC UA, MQTT/Sparkplug B, historian yazma) ve güvenlik seçenekleri (TLS, sertifika) destekleniyor.
• Tag ve sürücü lisanslama modeli toplam maliyete dahil edildi.
• Store-and-forward kalıcı depolamada; kapasite hedef kesinti süresine göre hesaplandı; dolma davranışı biliniyor.
• Depolama endüstriyel sınıf; yazma dayanıklılığı belirtilmiş.
• Montaj, besleme, sıcaklık ve çevre koşulları pano gerçeklerine göre kontrol edildi.
• İki arayüz arasında yönlendirme kapalı ve test edildi; gateway bağlantıları giden yönde kuruyor.
• Merkezi yönetim, imzalı güncelleme, geri dönüş ve yapılandırma yedeği mevcut.
• Cihaz sağlık metrikleri ve günlükler izleme sistemine bağlanıyor.
• Arıza durumunda yedek cihaz ve yapılandırma geri yükleme prosedürü yazılı ve en az bir kez denendi.

Gateway seçimi, pilot testi ve standart yapılandırma şablonu için edge gateway ve protokol dönüşümü, veri toplama mimarisinin tamamı için IIoT ve üretim verisi toplama sayfalarımıza bakabilirsiniz.

Sık sorulan sorular

Edge gateway yerine veriyi doğrudan SCADA’dan alamaz mıyız?

Alabilirsiniz; SCADA zaten PLC’leri okuyorsa onun OPC UA veya MQTT çıkışı iyi bir kaynaktır. Ama SCADA’nın okumadığı cihazlar, tamponlama ihtiyacı ve SCADA lisans veya yük sınırları ayrı bir edge katmanını gerekli kılabilir.

Store-and-forward kapasitesini nasıl belirleriz?

Saniyede oluşan değer sayısını, değer başına depolama boyutunu ve kabul edilebilir en uzun kesinti süresini çarpın; biçim ve indeks ek yükü için pay ekleyin. Değişim sıklığını tahmin etmeyin, pilot süresince ölçün.

Gateway hangi ağda durmalı: hücre ağında mı, DMZ’de mi?

Toplama yapan gateway genellikle okuduğu cihazlara yakın, hücre veya alan ağında durur ve DMZ’deki broker veya historian’a giden bağlantı kurar. Doğrudan DMZ’ye koymak PLC’lere DMZ’den erişim açmayı gerektirir; bu yüzden genellikle tercih edilmez.

Konteyner çalıştırabilen gateway her zaman daha mı iyidir?

Esneklik verir ama işletim sistemi, konteyner imajı ve güvenlik güncellemelerinin bakımını da size bırakır. Standart toplama ve yayımlama için hazır yazılımlı gateway daha az bakım ister; yerel hesaplama ve özel uygulama ihtiyacı varsa konteyner desteği anlamlıdır.