Redundant CPU'yu Kaldırdım, Failover 80 ms Sürdü: Ama O 80 ms Hat Durdurdu
Kocaeli'de bir tesiste S7-1500R/H çifti vardı. Bir CPU'yu test için kaldırdım, failover 80 ms sürdü — kağıt üzerinde 'mükemmel'. Ama o 80 ms, bir servo eksenin 'bilinmeyen konum' hatası vermesine yetti. Failover süresinin 'PLC dünyasında' değil 'süreç dünyasında' ölçülmesi gerektiğini kendi saha vakamla anlatıyorum.

Kocaeli’de bir tesis. Kritik bir hat: S7-1500R/H, yani redundant çift. Bir CPU aktif, diğeri hot-standby. Kağıt üzerinde, “aktif CPU düşerse, standby 80 ms içinde devreye girer, hat durmaz.”
Ben de buna inandım. Ta ki bir gün, bakım penceresinde, aktif CPU’yu test için fişten çekene kadar.
Failover gerçekleşti. 80 ms. TIA Portal’daki “Redundancy” ekranı, “Failover successful, 80 ms” dedi. Mükemmel. Kağıt üzerindeki sayıyla birebir.
Ama hat durdu.
80 ms Neden Yetti? (Yanıt: Yetmedi)
80 ms, PLC dünyasında mükemmel bir failover süresi. PLC’nin kendi döngüsü, I/O takası, program akışı — hepsi 80 ms içinde “devam etti”. Standby CPU, aktif CPU’nun son bilinen durumunu aldı, döngüye devam etti. PLC’nin gözünde, “hiçbir şey olmadı”.
Ama süreç dünyasında 80 ms, bir servo eksen için sonsuzluk.
Hat üzerindeki bir servo eksen, aktif CPU’dan “konum komutu” alıyordu. Failover anında, standby CPU, “son bilinen konum”u devraldı. Ama o 80 ms içinde, servo sürücü, “konum komutu gelmedi” diye 80 ms bekledi. 80 ms, servo sürücünün “komut yok” timeout’undan uzundu. Sürücü, “konum komutu kesildi” diye bilinmeyen konum (unknown position) hatası verdi. Eksen durdu. Hat durdu.
Yani, failover PLC tarafında başarılıydı. Ama sürücü tarafında başarısızdı. Ve hat, PLC’nin değil, sürücünün kararına göre durdu.
Failover Süresi İki Dünyada Ölçülür
Bu vakadan öğrendiğim şey şu: failover süresi, iki farklı saatle ölçülür.
- PLC saati: “Standby CPU, aktif CPU’nun durumunu ne kadar sürede devraldı?” Cevap: 80 ms. Bu, Siemens’in garanti ettiği, TIA Portal’ın gösterdiği sayı.
- Süreç saati: “Failover anında, dışarıdaki cihazlar (servo sürücü, VFD, güvenlik modülü) ‘komut kesildi’ diye ne kadar sürede tepki verdi?” Cevap: bu, cihazın kendi timeout’una bağlı. Servo sürücümüzde 50 ms’ti. VFD’lerde 100 ms. Güvenlik modülünde 20 ms.
Failover süresi, PLC saatinin değil, süreç saatinin en yavaş cihazından kısa olmalı. Yani, eğer hat üzerindeki en yavaş “komut yok” timeout’u 100 ms ise, failover süresi 100 ms’den kısa olmalı. 80 ms, 100 ms’den kısa — ama 50 ms’lik servo timeout’undan uzun.
İşte mesele buydu. 80 ms, “ortalama” için iyiydi, ama “en hassas cihaz” için kötüydü.
Ne Yaptım?
Üç şey:
- Servo sürücünün “komut yok” timeout’unu 200 ms’e çektim. Bu, failover süresinin (80 ms) üzerinde, ama “gerçek bir arıza” ile “failover”ı ayırt edecek kadar uzun. 200 ms, “failover olabilir” penceresi. 200 ms’den uzun kesinti, “gerçek arıza”.
- Failover anında, servo eksenin “hold” moduna geçmesini sağladım. Yani, failover sırasında, eksen “konum komutu bekleme” değil, “mevcut konumu koru” moduna girer. 80 ms içinde yeni CPU konum komutunu gönderir, eksen “hold”dan çıkar, devam eder.
- TIA Portal’da, failover süresini 80 ms’den 50 ms’e düşürdüm. Bu, redundant çiftin “sync” periyodunu sıkılaştırmakla mümkün. 50 ms, servo timeout’undan (200 ms) çok kısa. Artık failover, “komut yok” penceresinin içinde kalıyordu.
“Kağıt Üzerindeki Sayı” ile “Sahadaki Sayı”
Siemens’in datasheet’inde “failover < 100 ms” yazar. Bu, PLC’nin failover süresidir. Ama sahadaki gerçek failover süresi, PLC + en yavaş dış cihaz toplamıdır. Ve bu toplam, datasheet’te yazmaz. Çünkü “en yavaş dış cihaz”, sizin tesisinize, sizin hatınıza, sizin sürücünüze bağlıdır.
Bu yüzden, redundant bir sistem kurarken, şu soruyu sormak zorundasınız:
“Hat üzerindeki en hassas dış cihaz, ‘komut yok’ diye ne kadar sürede tepki veriyor?”
Cevap, failover sürenizin üst sınırını belirler. Ve bu sınır, PLC’nin datasheet’inde değil, sizin cihazınızın datasheet’indedir.
80 ms’nin Maliyeti
O test günü, 80 ms’lik failover, bir servo eksenin “bilinmeyen konum” hatası vermesine neden oldu. Eksen, yeniden “home” pozisyonuna gitmek zorunda kaldı. Bu, 12 dakika. 12 dakika × hat duruşu × saatlik maliyet.
Ama asıl maliyet, güven kaybıydı. Tesis, “redundant sistem”e güveniyordu. “CPU düşse bile hat durmaz” diyordu. O gün, “CPU düştü, hat durdu” oldu. Ve bu, “redundancy” kelimesinin tesis içindeki anlamını değiştirdi. Artık “redundant” demek, “hat durmaz” demek değildi. “Hat durmaz, ama dış cihazlarınızın timeout’ları failover sürenizden uzun olmalı” demekti.
Bazen en pahalı hata, “sistem çöktü” değil, “sistem çalıştı ama dış dünya çalışmadı”tır.