PLC'yi Ağ'a Bağlarken: "Abi Laptopu Taktım Da Neden Göremiyorum?"

Geçen hafta bir devreye gittik. Üçüncü katta, henüz kliması da açılmamış bir binanın otomasyon odası. Mühendis arkadaşım masaya oturdu, laptopu açtı, kabloyu switch’e taktı, TIA’yı çıkardı. Beş dk sonra bana baktı: “Abi bu PLC neden yok?”

O cümle, otomasyon sahasının en kadim sorusudur. “Abi LAN kartı mı?” diye başlayan ve saatler süren dedikodularla devam eden o klasik sahne. Hemen ekleyeyim, bu sorunun cevabı %90’ı zamanla ilgili değildir, ayla ilgilidir. Yani “şeyi yap da bitsin” mantığıyla yaklaşınca bitmez. Biraz sabır ve sıralı kontrol lazım.

Nasıl mı? Gidelim baştan.

Önce IP, Sonra Her Şey

Laptopun Ethernet portuna statik IP veriyorsun, diyoruz ama çoğu zaman aslı astarı belli olmayan bir IP veriyoruz. Mesela PLC’nin olduğu ağ 10.1.25.x aralığında çalışıyorsa, laptopuna 192.168.1.5 vermekle hiçbir yere varamazsın. Bu, otomasyon sahasındaki en sık kafa karışıklığı. Bir kere kabloyu taktıktan sonra, TIA’dan önce, cmd’i açıp şu üç komutu çalıştır.

ipconfig ile laptopun fiilen aldığı IP’yi gör. Kablolu portun “otomatik IP atadı” modunda mı, yoksa senin verdiğin statik değerde mi olduğunu anlamak kritik. Birçok firmada laptop, Wi-Fi ve Ethernet portu arasında geçiş yapınca, Ethernet tarafı “DHCP’den alayım” modunda kalır. DHCP sunucusu da o segmentte yoksa, sana 169.254.x.x gibi bir link-local adres takar. Bunu gördüğün an, “PLC göremiyorum” meselesi kapanır; problem IP’dedir, PLC değildir.

Sonra ping testi. Ama işin püf noktası şu: PLC’nin IP’sine ping atmak, her zaman cevap demek değildir. Bunu söylemeden geçmeyeyim çünkü en çok buradan yarılanız var. Birçok modern S7-1200/S7-1500 serisinden CPU, default ayarıyla ICMP’yi filtrelemiyordur ama panodaki switch, ağın genel politikası veya PLC’nin kendi güvenlik ayarı buna müsaade etmeyebilir. Ping atıyorsun, cevap yok, “PLC ölü” diye panik yapıyorsun. Oysa sorunun asıl kaynağı, ping değil, TCP port 102 ve 1021 üzerindeki S7 iletişimi olabilir.

TIA “Bağlanıyor” Göstergesinde Dönüyor

TIA Portal’da PLC’yi online alırken o meşhur saatler dönüyor. Bu durumda, %60’ı zamanla, %40’ı da şuna inat: laptopun, switch’in ve PLC’nin aynı L2 domain içinde olmadığı. Yani kablo fiziksel olarak switch’e takılı, ama switch portları VLAN’a bölünmüştür ve senin laptopun “yönetim” VLAN’ında, PLC’ninki “otomasyon” VLAN’ında oturuyor olabilir. VLAN kavramı, IT tarafında standart bir iş, OT tarafında ise çoğu zaman “abi ben bilmiyorum, sadece kablo çektim” ile geçiştirilen bir konu.

Saha kokan pratik test şu: switch’e ulaşıp (web arayüzü olsa, CLI olsa), laptopun portuyla PLC’nin portunun aynı VLAN’da olup olmadığını sor. Birebir biliyorsan, laptopu geçici olarak PLC’nin kabladığı aynı port grubuna, mümkünse PLC’nin kendi ana portuna paralel alma. Ya da en basiti: laptopu doğrudan PLC’nin ethernet portuna, crossover değil, düz kablolarla bağla. Modern cihazların otomatik MDI-X olması sayesinde düz kablo yeter. Bu testten PLC’ye ulaşabiliyorsan, suç kesinlikle switch ya da VLAN konfigürasyonundadır. Bileği bükülebilir bir kanıt elde edersin ve “PLC bozuk” diye gereksiz bir servisa gerek kalmaz.

Saat Uyuşmazlığı: “PLC Saati Neden Bozuluyor?”

Bu, ayrı bir başlık bile olur ama burada geçer çünkü ağ’la iç içe. PLC’ye saat verirken NTP server’a işaretliyorsun. Lakin otomasyon ağında NTP server’ın IP’si de çoğu zaman aynı segmentte yok, ya da firewall o trafiği (UDP 123) açmıyor. Sonuç: PLC, kendi kristal osilatörüne güvenerek saat tutar. Kristal osilatörler günlük birkaç milisaniyeden, aylık birkaç dakikaya kadar sapma yapabilir. Hattın başında bir “kayıt zamanı” işlemin varsa, o kayıtların zaman damgası bir süre sonra senin SCADA/MES tarafındaki “gerçek” zamandan kopar. Veri analizi yaparken “gece vardiyasında üretim düşmüş” diye bakıyorsun, aslında düşüş yok, sadece zaman damgaları farklı. Üstelik bu kopma, PLC’yi tekrar resetlediğinde de sıfırdan yaşanır.

Pratik çözüm basit ama uygulanması sık ihmal edilen bir şey: NTP server’ı doğru IP’ye, doğru segmente yerleştir ve firewall’un otomasyon VLAN’ına UDP 123’ü aç. Ya da daha güvenli bir tercih olarak, NTP trafiğini ağın genel “yönetim” tarafına değil, otomasyon tarafına özel bir iç sunucudan ver. Çünkü saha, “PLC’nin internete bağlan” dedirten bir ortam değil; ama en azından ağın içinde tutarlı saat olması için bir referansın olsun.

Peki Ya Güvenlik?

Bunu yazmak teknik değil, vicdani bir yükümlülük aslında. Laptopu switch’e takıp TIA ile bağlandığın anda, o laptop, ağın içinde “güvenilir” bir cihaz olarak sayılıyor. Gerçekte ise çoğu saha laptopu güncel antivirüs güncellemesinden, yama günlerinden, hatta şifre politikasından düşüktür. 2026 itibarıyla, özellikle TIA V21’den sonra, Siemens tarafı IT/OT ayrımını daha sert kuruyor; Git entegrasyonu, Cloud ve Copilot akışları, hep “ağ güvenli, kimlik doğrulanmış” varsayımına dayanıyor. TIA V21’in ne getirdiğini geçenlerde inceleme yapmıştım, ilgini çekebilir.

Sahanın hızlı işi için asgari kurallar şunlar:

• Laptopa, saha ağına girmeden önce, o ağa özel bir “sağlama” yap: antivirüs güncel, işletim sistemi patch’i güncel, şifre güçlü.
• PLC’ye bağlandığın portu, mümkünse, sadece senin kullandığın bir “yönetim” segmentine al; üretim segmentine karıştırma.
• Bağlantıyı bitirdiğinde, kabloyu sök, laptopu ağdan al. “Bırakayım, yarın yine lazım olur” düşüncesi, bir sonraki “abi bu PLC neden yavaş?” sorusunun nedeni olur.
• Uzak bağlantı (remote maintenance) gerekiyorsa, doğrudan PLC’ye VPN değil, araya mutlaka bir jumpbox ya da secure remote access katmanı koy. “PLC’nin portu açık, SSH de aç, hallederiz” mantığı, sahada işe yararsa da güvenlik tarafında bir borç biriktirir.

Küçük Bir Not: Simülasyonda Alışkanlık Kazanmak

Bu yazıyı neden yazdığımı da söyleyeyim. Saha, bu konularda “kafadan” değil, “alışkanlıktan” çözülen yerler. IP vermek, VLAN sorgusu yapmak, ping ve port testini sırasıyla yapmak, bunlar otomatik reflekse dönmedikçe her devrede yeniden “abi niye çalışmıyor?” döngüsü yaşanır. Biz de bu yüzden web tabanlı PLC simülasyonumuzla bu alışımları, gerçek bir fabrika baskısı olmadan, tekrar tekrar yapman için tasarladık. Ladder’dan SCL’e, protokol mantığından devreye alma senaryolarına kadar, önce sanal ortamda “yanlış yapmak” rahatlığı var. Çünkü sahadaki ilk “yanlış”ın maliyeti, her zaman simülasyondan pahalıdır.

Kısacası, tekrar başa dönecek olursak: “Abi laptopu taktım da neden göremiyorum?” sorusunun cevabı, büyük ihtimalle PLC’den çok IP, VLAN ve güvenlik katmanlarında gizlidir. Ve çoğu zaman, panik yapmadan üç-beş dakika ayırıp sıralı kontrol yapınca, o “PLC ölü” sandığın cihaz, senin laptopunun yanlış segmentte durmasıyla alakalıdır. Bileğini bükmek, önce kendine sormakla başlar: “Ben, şimdi, hangi ağda, hangi portta, hangi IP ile oturuyorum?”

Cevabı bilene kadar, o kaba bakmayı bırak. Cevap, ekrandaki o dönen saatte değil, senin soru sorma sıranında.