PROFINET Arıza Teşhisi: Hata Sayaçları, Topoloji ve Paket Analizi

PROFINET’te insanı en çok yoran arıza kalıcı olmayanıdır. IO cihazı haftada birkaç kez düşer, kendiliğinden geri gelir; bakım kabloyu değiştirir, sorun bir süre kaybolur, sonra yeniden başlar. Parça değiştirerek bu döngüden çıkılmaz. Aralıklı cihaz düşmeleri, watchdog hataları ve “device not found” gibi belirtiler için kullandığımız kontrol sırası şu: mühendislik yazılımından fiziksel katmana, oradan paket analizine inen ve her adımda bir olasılığı eleyen katmanlı bir prosedür.

Önce belirtiyi sınıflandırın: kalıcı, aralıklı, yük bağımlı

Teşhise başlamadan arızanın karakterini yazılı hâle getirin. Hangi aracı kullanacağınızı bu sınıflandırma belirler:

• Kalıcı arıza: Cihaz hiç bağlanmıyor veya sürekli “device not found” veriyor. Genellikle yapılandırma (cihaz adı, IP, GSDML sürümü, topoloji ataması) ya da kesin bir fiziksel kopukluktur.
• Aralıklı arıza: Cihaz düşüp birkaç saniye içinde geri geliyor. Tipik nedenler gevşek konnektör, hasarlı kablo, ekran/topraklama sorunu kaynaklı bozuk çerçeveler veya ağda dönem dönem oluşan trafik patlamalarıdır.
• Yük veya olay bağımlı arıza: Sorun yalnız belirli bir motor çalıştığında, vardiya başında, yedekleme saatinde veya bir mühendislik PC’si ağa bağlandığında çıkıyor. EMI veya PROFINET dışı trafik (IT trafiği, multicast, yayın fırtınası) güçlü şüphelilerdir.

Her olay için zaman damgasını, etkilenen cihazları ve o anda sahada ne olduğunu kaydedin. “Dün akşam yine düştü” bilgi değildir. Birden fazla cihaz aynı anda düşüyorsa sorun çoğunlukla ortak yoldadır: aynı switch, aynı uplink ya da zincirde ilk düşen cihazın önündeki bağlantı.

Mühendislik yazılımında online teşhis ve alarm tamponu

İlk adım controller’ın gördüğünü okumaktır. TIA Portal’da çevrimiçi bağlanıp teşhis tamponunu (diagnostic buffer) inceleyin; her cihaz arızası ve geri dönüşü burada zaman damgasıyla listelenir. Controller saati bir NTP kaynağıyla senkron değilse bu damgaları switch log’larıyla karşılaştıramazsınız. Sahada en sık atlanan ayarlardan biri budur.

Teşhis tamponunda şu ayrımları yapın:

• Station failure (cihaz arızası): Controller cihazdan watchdog süresi boyunca veri alamadı. İletişim yolu kesilmiştir; neden ağda ya da cihazın enerjisindedir.
• Cihaz kaynaklı teşhis alarmları: Modül arızası, kanal hatası, besleme eksikliği gibi alarmları cihaz PROFINET alarm çerçeveleriyle gönderir. Bunlar iletişim sorunu değil, cihazın raporladığı durumlardır.
• Port ve senkronizasyon teşhisleri: Birçok cihaz port bazında link kaybı, komşu uyuşmazlığı ve iletim hatası eşiği aşımı gibi teşhisleri raporlar. Bunlar fiziksel katman sorunlarının doğrudan habercisidir.

Siemens’in ücretsiz aracı PRONETA, mühendislik projesine erişim olmadan ağı tarayıp cihaz adı, IP ve topoloji bilgisini listeler. Sahada “bu cihaz gerçekten hangi isimle yanıt veriyor?” sorusunun en hızlı cevabıdır.

Switch port istatistikleri ve fiziksel katman kontrolü

Endüstriyel ağ altyapısındaki aralıklı arızaların büyük kısmı fiziksel katmanda başlar ve switch port sayaçlarında iz bırakır. Yönetilebilir switch’te sayaçları sıfırlayıp belirli bir süre sonra tekrar okuyun; hangi bağlantının hata ürettiği ortaya çıkar. Cisco IOS tabanlı endüstriyel switch’lerde örnek komutlar:

! Sayaçları sıfırla, gözlem süresinin başlangıcını not al
clear counters GigabitEthernet1/0/5

! Hata sayaçlarını port bazında listele
show interfaces counters errors

! Tek port ayrıntısı: CRC, input errors, runts, giants, late collision
show interfaces GigabitEthernet1/0/5

! Link durum değişiklikleri log’da görünür
show logging | include GigabitEthernet1/0/5

Sayaçları okurken şu ilişkiler yol gösterir. CRC ve FCS hataları bozuk kablo, hasarlı konnektör, EMI veya ekran sürekliliği sorununa işaret eder. Late collision ve tek tarafta artan hata sayısı çift yönlülük (duplex) uyuşmazlığının klasik belirtisidir. Bağlantının iki ucu aynı modda çalışmalıdır: tipik PROFINET portunda otomatik anlaşma (autonegotiation) açıktır; Fast Start-Up veya bazı fiber bağlantılar gibi sabit ayar gereken durumlarda ise iki uç da 100 Mbit/s tam çift yönlüye sabitlenir. Yalnız bir tarafı sabitlemek bu uyuşmazlığın en sık nedenidir. Çıkış tarafında düşen paketler (output drops) uplink’in tıkandığını veya QoS önceliklendirmesinin çalışmadığını gösterir.

Yönetilmeyen switch’lerin veya cihazların gömülü switch’lerinin sayaçlarına SNMP ya da mühendislik aracıyla erişebiliyorsanız aynı analizi yapın. Sayacında hata görülen bağlantıda kablo ölçümü şarttır. Süreklilik testi yetmez. PROFINET hattında kablo sertifikasyon cihazıyla NEXT, dönüş kaybı ve ekran sürekliliği kontrol edilmelidir. Ekranlı kablonun her iki uçtan topraklanması ve eş potansiyel bağlama, PROFINET kurulum yönergelerinin temel gereklilikleridir; frekans konvertörü kablolarıyla aynı kanaldan geçen PROFINET kabloları sahada sık karşılaştığımız bir EMI kaynağıdır.

LLDP ile gerçek ve planlanan topolojiyi karşılaştırın

PROFINET cihazları komşularını LLDP ile tanır. Bu bilgi iki iş görür: mühendislik yazılımındaki planlı topolojiyi sahadaki gerçek bağlantılarla karşılaştırmak ve cihaz değişiminde yeni cihaza adı otomatik atamak. TIA Portal’ın topoloji görünümündeki çevrimiçi karşılaştırma, hangi portun hangi cihazın hangi portuna bağlı olduğunu planla yan yana gösterir.

Aranan bulgular şunlar: projede tanımlı olmayan bir switch veya cihazın araya eklenmesi, kabloların port değiştirmesi (örneğin ring portu yerine üçüncü porta takılması) ve planlanandan farklı bir zincir sırası. Topoloji tanımlı ve “komşu kontrolü” etkin bir projede port değişikliği teşhis üretir; cihaz yine çalışabilir ama otomatik cihaz değişimi bu durumda beklendiği gibi işlemez. Switch tarafında komşular şu komutla doğrulanır:

show lldp neighbors
show lldp neighbors GigabitEthernet1/0/5 detail

Planla uyuşmayan her bağlantı ya düzeltilir ya da proje güncellenir. Ortası yok. Belgelenmemiş değişiklik, bir sonraki arızada teşhisi en çok yavaşlatan şeydir.

Port mirroring ve Wireshark ile PROFINET paket analizi

Önceki adımlar sorunu daraltmadıysa sıra paket analizine gelir. Arızalı cihaza en yakın yönetilebilir switch’te port aynalama (SPAN) yapın veya cihaz ile switch arasına bir ağ TAP’i yerleştirin. Cisco IOS’ta örnek SPAN yapılandırması:

monitor session 1 source interface GigabitEthernet1/0/5 both
monitor session 1 destination interface GigabitEthernet1/0/24

Aynalama portu kaynak portların toplam trafiğini taşıyamazsa çerçeve kaybeder ve sizi yanlış teşhise götürür; yüksek trafikli portlarda TAP tercih edin. PROFINET RT çerçeveleri öncelik bilgisini taşıyan bir VLAN etiketiyle iletilebilir; bazı ağ kartı sürücüleri bu etiketi kaldırdığı için yakalama yapan PC’nin kartını etiketleri koruyacak şekilde ayarlamanız gerekebilir.

Wireshark’ta işe yarayan görüntüleme filtreleri (# işaretinden sonrası açıklamadır, filtreye yazılmaz):

pn_dcp                                   # Cihaz adı ve IP atama/tanıma (DCP)
eth.type == 0x8892                       # Tüm PROFINET RT çerçeveleri
pn_rt.frame_id >= 0x0100 && pn_rt.frame_id < 0xfc00   # Çevrimsel veri (RT/IRT)
pn_rt.frame_id == 0xfc01 || pn_rt.frame_id == 0xfe01      # Yüksek/düşük öncelikli alarmlar
lldp                                     # Komşuluk bilgisi
pn_io                                    # Bağlantı kurulumu ve kayıt okuma (RPC)

Yakalamada dört şeye bakın. Çevrimsel veri zamanlaması: Tek bir cihazın çevrimsel çerçevelerini kaynak MAC ile süzüp ardışık çerçeveler arasındaki süreyi incelediğinizde, güncelleme süresinden belirgin sapmalar ve boşluklar ağ kaynaklı gecikmeyi gösterir. DCP trafiği: Çalışan bir hatta beklenmedik DCP Set istekleri, birinin cihaz adını veya IP’sini değiştirdiğini gösterir; aynı isme iki cihazın yanıt vermesi isim çakışmasıdır. Alarmlar: Cihazın düşmeden hemen önce alarm gönderip göndermediği, sorunun cihaz içinde mi yoksa iletim yolunda mı olduğunu ayırır. PROFINET dışı trafik: Aynı anda yoğun broadcast, multicast veya büyük dosya transferi görüyorsanız sorun ağ ayrımındadır. Genel paket yakalama teknikleri için Wireshark ile ağ paket analizi rehberi ve Wireshark dokümantasyonu iyi başlangıç noktalarıdır.

Belirti, olası neden ve kontrol tablosu

Belirti	Olası neden	Kontrol
Device not found	Cihaz adı veya IP uyuşmazlığı	PRONETA/DCP ile gerçek adı oku
İki cihaz dönüşümlü düşüyor	Aynı cihaz adı veya IP çakışması	pn_dcp ile yanıt veren MAC’leri karşılaştır
Zincirde arkadaki tüm cihazlar düşüyor	Zincirdeki ilk düşen cihazın önündeki bağlantı	O bağlantının port sayaçları ve kablo testi
CRC/FCS sayacı artıyor	Kablo, konnektör, EMI, ekran sorunu	Sertifikasyon ölçümü, güzergâh ve topraklama
Late collision	Duplex uyuşmazlığı	İki tarafta autonegotiation ayarı
Belirli saatlerde düşme	Yedekleme, IT trafiği, multicast	Output drops ve o saatte paket yakalama
Kablo çekilince ring’e rağmen düşme	Watchdog < ring kurtarma süresi	Watchdog ve MRP ayarları

Ring yapılandırmasıyla ilgili bulgularda PROFINET MRP ring topolojisi yazısındaki kesme testini tekrarlayın. Tasarım kaynaklı kök nedenler ise çoğunlukla PROFINET ağ tasarımı hatalarıyla örtüşür.

Arıza kapandıktan sonra: kalıcı izleme

Kök neden bulunup giderildiğinde iş bitmiş sayılmaz. Aynı sorun tekrar ederse daha hızlı yakalamak için izlemeyi kalıcı hâle getirin:

• Yönetilebilir switch’lerin port hata sayaçlarını ve link durum değişikliklerini SNMP ile periyodik toplayın; artış eğilimi için eşik tanımlayın.
• Switch ve controller log’larını zaman senkronlu biçimde merkezi bir sunucuya gönderin.
• Kritik uplink’lerde kalıcı bir TAP veya aynalama noktası bırakın; bir sonraki olayda kablo sökmeden yakalama yaparsınız.
• Gerçek topolojiyi, cihaz adlarını ve IP’leri her değişiklikten sonra projeyle karşılaştırıp güncelleyin.
• Her arızanın belirti, kök neden ve çözümünü kısa bir kayıtla arşivleyin; aralıklı arızalarda örüntüyü geçmiş kayıtlar gösterir.

Bu izleme yapısının tasarımı ve kalıcı arıza analizi için endüstriyel ağ izleme ve arıza analizi hizmet sayfamıza, PROFINET projelerinin yeniden düzenlenmesi için PROFINET ve PROFIBUS haberleşme sayfasına bakabilirsiniz.

Sık sorulan sorular

PROFINET arıza teşhisine nereden başlanmalı?

Önce controller teşhis tamponundan arızanın zamanını ve etkilenen cihazları okuyun. Ardından ortak iletim yolundaki switch port sayaçlarına, LLDP topoloji karşılaştırmasına ve gerekiyorsa paket yakalamaya bu sırayla geçin.

Wireshark’ta PROFINET trafiği neden görünmüyor?

Yakalama noktası yanlış olabilir; switch trafiği yalnız ilgili portlara iletir. Port aynalama veya TAP kullanın. Ayrıca bazı ağ kartı sürücüleri VLAN etiketini kaldırır; kartı etiketleri koruyacak şekilde ayarlamanız gerekebilir.

CRC hataları neyi gösterir?

CRC veya FCS hatası çerçevenin iletim sırasında bozulduğunu gösterir. Tipik nedenler hasarlı kablo veya konnektör, ekran ve topraklama sorunları ve güç kablolarına yakın güzergâhtan gelen elektromanyetik girişimdir.

Device not found hatası her zaman kablo arızası mıdır?

Hayır. En sık neden, cihaz adının veya IP adresinin projedekiyle uyuşmamasıdır. Cihaz değişiminden sonra ad atanmamış olması veya iki cihazın aynı adı taşıması da bu hatayı verir.