Tüm yazılar
Haberleşme

Allen-Bradley ve S7 Aynı Switch'te: Ethernet/IP'nin 'Gizli' Mesajı Hattı Doldurdu

Bursa'da bir tesiste ControlLogix ile S7-1500 aynı Ethernet segmentinde yaşıyordu. Bir CIP cihazı eklendi, implicit mesajlar hattı doldurdu, Profinet tarafında jitter çıktı. 'Gizli' mesajın ne olduğunu, neden TCP gibi şekillendirilemediğini ve segmenti nasıl ayırdığımızı kendi saha vakamla anlatıyorum.

Allen-Bradley ve S7 Aynı Switch'te: Ethernet/IP'nin 'Gizli' Mesajı Hattı Doldurdu

Bursa’da bir tesis. Hat iki markayla kurulu: bir tarafta Allen-Bradley ControlLogix, diğer tarafta Siemens S7-1500. İkisi de aynı L2 segmentinde, aynı managed switch’in portlarında. Beş yıldır böyle çalışıyordu, kimse bir şey dememişti. Ta ki bir gün hat üzerindeki bir CIP cihazı — bir güvenlik modülü — eklenene kadar.

O gün operatör şunu söyledi: “Profinet tarafındaki iki eksen ara ara takılıyor, 200 ms’de bir bir kare atlıyor.”

200 ms. Bu sayıyı duyan bir otomasyon mühendisinin aklına ilk gelen şey “kablo” ya da “CPU yükü” olur. İkisini de elledim, ikisi de temizdi. Sorun ne kablodaydı ne de CPU’daydı. Sorun, hattın kendisindeydi — ama görünmeyen bir trafik türünde.

Ethernet/IP’de İki Mesaj Var, Biri ‘Gizli’

Ethernet/IP, CIP (Common Industrial Protocol) üzerine kurulu. CIP’nin iki mesaj tipi var:

İkinci tip, yani implicit, “gizli” olan. Çünkü explicit gibi TCP akışı gibi görünmez; switch’in gözünde “normal Ethernet frame”dir. QoS politikası onu “CIP implicit” olarak etiketlemediğin sürece, onu “kritik I/O” değil, “herhangi bir frame” sanır.

Tesisimizde eklenen güvenlik modülü, implicit messaging ile 1 ms periyotta I/O akışı yapıyordu. 1 ms. Yani saniyede 1000 frame. Ve bu frame’ler, Profinet RT trafiğiyle aynı segmentde, aynı öncelikte, aynı kuyrukta bekliyordu.

Neden TCP Gibi Şekillendirilemedi?

Explicit mesaj TCP üstünde gittiği için, switch’in QoS motoru onu tanıyabiliyordu: “Bu TCP, bu port, bu öncelik.” Ama implicit mesaj, bağlantı kurulduktan sonra, CIP’nin kendi bağlantı tablosu üzerinden akar. Switch, o frame’e baktığında “Ethernet frame, VLAN 20, DSCP 0” görür. DSCP 0. Yani “önceliği yok.”

Profinet RT tarafı ise DSCP 48 (EF) ile gidiyordu. Teoride Profinet kazanmalıydı. Ama pratikte, implicit frame’lerin hacmi o kadar büyüktü ki, aynı fiziksel portun aynı egress kuyruğunda Profinet frame’lerini “itip” geciktiriyordu. QoS, “öncelik” verir, “bant genişliği ayırma” vermez. Kuyruk dolarsa, öncelikli frame de bekler.

İşte 200 ms’lik kare atlaması buydu. Profinet RT frame’i, implicit CIP trafiğinin oluşturduğu kuyrukta 200 ms bekliyordu.

Segmenti Ayırmak: 40 Dakika, Ama Doğru Yerde

Çözüm, “switch’i değiştir” ya da “kablo kalınlığı artır” değildi. Çözüm, iki trafiği farklı segmentlere koymaktı.

Yaptığım üç adım:

  1. VLAN ayrımı. CIP implicit trafiğini (güvenlik modülü + ControlLogix I/O) VLAN 30’a, Profinet RT trafiğini VLAN 20’ye aldım. Aynı fiziksel switch, ama farklı L2 domain’leri.
  2. DSCP etiketleme. CIP tarafında, switch’in port bazlı QoS’ine “bu porttan gelen frame’lere DSCP 24 (CS3) at” kuralı koydum. Artık implicit frame’ler “önceliği yok” değil, “orta öncelik” taşıyordu.
  3. Egress kuyruk ayırma. Switch’te, VLAN 20 (Profinet) için ayrı bir egress kuyruğu tanımladım. Artık iki trafik, aynı fiziksel portta bile, farklı kuyruklardan çıkıyordu.

Bu üç adım, switch’in konfigürasyon ekranında 40 dakika sürdü. Ama “doğru yerde” yapmanız gerekiyordu. Yanlış VLAN’da, yanlış DSCP ile, aynı kuyrukta kalsaydınız, 40 dakikanın hiçbir anlamı olmazdı.

“Gizli” Mesajı Görmek İçin Ne Kullandım?

Burada dürüst olayım: implicit trafiği “görmek” için Wireshark yetmedi. Wireshark, CIP’yi çözer ama “bu frame implicit mi explicit mi” ayrımını, bağlantı tablosunu okumadan yapmaz. Ben, ControlLogix’in kendi CIP bağlantı tablosunu (Connection Manager) dump’layıp, hangi CIP instance’larının implicit olduğunu, periyotlarını ve boyutlarını çıkardım. Sonra, switch’in port istatistiklerinde, o periyotla eşleşen frame sayısını doğruladım.

1 ms periyot, 1000 frame/sn. Switch’in o portundaki frame sayacı, tam 1000/sn artıyordu. Eşleşme netti.

Masada 40 Dakika, Sahada 3 Gün

Bu ayrımı, laboratuvarda, aynı switch ile, aynı iki marka ile kurmak 40 dakika. Sahada 3 gün sürdü. Çünkü:

Yani, teknik çözüm 40 dakikaydı. Ama o 40 dakikanın “hat durabilir” penceresine sığması, 3 gün aldı.

Bir Cihaz Eklemeden Önce Sorduğum Soru

O günden sonra, bir tesiste yeni bir CIP cihazı eklenmeden önce, şu üç soruyu sorar oldum:

  1. Bu cihaz implicit mi explicit mi kullanıyor? Implicit ise, periyodu ne?
  2. Hangi segmente girecek? O segmentte zaten kritik RT trafiği var mı?
  3. Switch, o segmentte egress kuyruk ayırma yapabiliyor mu?

Bu üç sorunun cevabı “evet, implicit, 1 ms, evet aynı segmentte Profinet var, hayır kuyruk ayırma yok” ise, o cihazı eklemem. Önce segmenti ayırırım, sonra cihazı eklerim.

Tesis hâlâ çalışıyor. İki marka, aynı switch, farklı segmentler. Operatör o 200 ms’lik kare atlamasından beri bir daha bahsetmedi. Bazen en sessiz çözüm, en iyi çözümdür.