Endüstriyel Protokol Seçimi: Bir Eleme Çerçevesi

Protokol seçimi bir hız yarışı değil

Yeni bir makine ya da hat için ağ protokolü seçmek çoğu ekipte "hangisi daha hızlı" sorusuyla başlar ve bir karşılaştırma tablosuyla biter. O tablo yanlış değildir, sadece kararı vermez. Protokol kararı bir yazılım kararı değildir: konnektör tipini, kablo kanalını, satın alınabilecek sürücü markalarını, devreye alma aletini, sahadaki teknisyenin zaten bildiği şeyi ve on yıl sonraki yedek parça listesini birlikte bağlar. Yazılım mimarisi iki yılda bir yeniden yazılabilir; kablo kanalı ancak makine dururken değişir.

Bu yüzden protokol seçimini bir seçme değil bir eleme problemi olarak kurmak gerekir: adayları puanlamak yerine, projenin kısıtlarını sorulara çevirip tek tek düşürmek. Sonunda tek aday kalırsa karar verilmiştir; iki aday kalırsa karar teknik değil ekosistem kararıdır ve öyle imzalanmalıdır.

Adayların kısa künyesi

Ortak zemin olsun diye beş adayı tanımlarıyla koyalım. Tablodaki her satır bir tanım ya da standart maddesidir; performans iddiası değildir.

Son satır kritik. TSN diğer dördüyle aynı kümede değildir: bir fieldbus değil, üzerinde fieldbus taşınan bir anahtar davranışıdır. "TSN'e geçelim" cümlesi, "hangi uygulama protokolünü TSN üzerinde koşturacağız" sorusunu cevaplamaz. Endüstriyel otomasyon için bu boşluğu kapatan profil IEC/IEEE 60802 olarak yazılmaktadır.

Kararı bağlayan altı eksen

1. Çevrim süresi mi, senkronizasyon doğruluğu mu

En sık karıştırılan iki büyüklük bunlardır. Çevrim süresi, süreç verisinin ne sıklıkta tazelendiğidir. Senkronizasyon doğruluğu, hattaki iki farklı cihazın aynı anı ne kadar aynı gördüğüdür. Bir hat kısa çevrimle dönüp cihazlar arasında büyük bir kayma taşıyabilir; bu, hızlı ama senkron olmayan bir hattır.

Ayrım pratikte şuraya bağlanır: koordineli hareket senkronizasyon doğruluğu ister, veri toplama çevrim süresi ister. İki eksende bağımsız interpolasyon yapan bir CNC ya da kesme senkronizasyonu yapan bir paketleme makinesi, ortak bir saat tabanı olmadan kabul edilebilir bir profil üretemez. Yüz noktadan sıcaklık ve basınç toplayan bir tesis ise saniyede birkaç örnekle mutludur ve ortak saate ihtiyaç duymaz.

Ortak saat tabanı EtherCAT'te Distributed Clocks ile protokolün içindedir. PROFINET'te IRT sınıfı zamanlanmış iletim sunar ve plan mühendislik aracında üretilir. TSN tarafında saat IEEE 802.1AS ile gelir. Modbus TCP'nin ve klasik CANopen'ın zaman modeli yoktur — CANopen'ın SYNC mesajı bir tetikleyicidir, bir saat değildir.

2. Topoloji ve kablolama

Topoloji sorusunun cevabı çoğu zaman makinenin mekanik yerleşiminde yazılıdır: robot kolu boyunca dizilen eksenler doğal bir hattır, panoya toplanan I/O yıldızdır, konveyör boyunca uzayan istasyonlar hem hat hem dallanma ister.

İki fiziksel kısıt kararı sıkıştırır. Birincisi mesafe: IEEE 802.3'ün bakır Ethernet segment sınırı 100 m'dir, ötesi fiber ya da ara anahtar demektir. Süreç endüstrisinde IEEE 802.3cg ile tanımlanan 10BASE-T1L tek çift Ethernet çok daha uzun mesafeler hedefler, karşılığında bit hızını düşürür. İkincisi CAN tarafındaki değiş tokuş: ISO 11898-2'nin fiziksel katman kısıtları gereği bit hızı yükseldikçe kullanılabilir hat uzunluğu düşer ve dallanma (stub) toleransı CAN FD'nin veri fazında klasik CAN'a göre belirgin biçimde daralır. Uzun ve dallı bir hatta CAN FD'ye geçmek çoğu zaman transceiver seçimini de değiştirir; CiA 601-4'te tanımlanan sinyal iyileştirmeli (SIC) sürücüler tam bu sorun için vardır.

3. Cihaz sayısı ve süreç verisi bütçesi

Adres alanı ve çerçeve sınırları tanım gereği sabittir, yani hesap yapılabilir. CANopen'ın klasik 11 bitlik tanımlayıcı düzeninde node-ID alanı 7 bittir; CiA 301 bunu 1–127 aralığı olarak tanımlar. Modbus'ta tek bir Read Holding Registers isteği (fonksiyon kodu 0x03) spesifikasyona göre en çok 125 register döndürür, Write Multiple Registers (0x10) en çok 123 register yazar; MBAP başlığı dâhil bir Modbus TCP ADU'su 260 baytı geçmez.

Hesap şöyle kurulur: cihaz başına giriş + çıkış baytı × cihaz sayısı = çevrim başına taşınacak süreç verisi. Bu toplam seçilen protokolün çerçeve kapasitesini aşarsa veri birden fazla çerçeveye bölünür ve hedef çevrim süresi artık tek çerçeveye değil, bölünmüş çerçevelerin toplamına göre değerlendirilmelidir. Kırılma noktası protokolün kusuru değil, çerçeve limitinin doğal sonucudur; aynı etkinin gerçek bir tezgâhta nasıl göründüğünü EtherCAT ölçüm metodolojisi yazımızda anlatmıştık.

4. Ekosistem ve cihaz tanım dosyaları

Her protokolün bir cihaz tanım dosyası vardır ve devreye alma pratiği bu dosyanın etrafında döner: EtherCAT'te ESI (XML), PROFINET'te GSDML, CANopen'da EDS/DCF. Modbus TCP'de standart bir tanım dosyası yoktur — register haritası bir PDF'ten elle çıkarılır. Modbus'ı hem "kolay" gösteren hem de en kırılgan yapan şey budur: haritayı doğrulayacak, makine tarafından okunabilir bir sözleşme ortada yoktur.

Ekosistem sorusunun asıl karşılığı satın alma masasındadır. Seçtiğiniz protokolü konuşan servo sürücüyü, enkoderi, güvenlik modülünü ve uzak I/O'yu kaç farklı üreticiden alabiliyorsunuz? Tek kaynak varsa protokol seçimi aslında tedarikçi seçimidir; kararı öyle yazın.

5. Fonksiyonel güvenlik aynı kablodan mı geçecek

Bu soru sonradan sorulduğunda pahalıya patlar. Güvenlik fonksiyonlarını ayrı bir sert kablolamayla mı taşıyacaksınız, yoksa aynı ağ üzerinden mi? İkincisi için protokolün bir güvenlik profili olması gerekir: EtherCAT tarafında FSoE (IEC 61784-3-12), PROFINET tarafında PROFIsafe (IEC 61784-3-3), CAN tarafında EN 50325-5 olarak yayımlanan CANopen Safety. Modbus TCP'nin böyle bir profili yoktur.

Dikkat: bu profillerin varlığı sistemi güvenli yapmaz. Güvenlik gereksiniminin kendisi risk değerlendirmesinden çıkar, doğrulama yükü sistem entegratöründedir. Protokol seçimi yalnızca "bu yol açık mı" sorusuna cevap verir.

6. Uygunluk testi yükü

Cihaz üretiyorsanız bu eksen doğrudan takvim ve bütçe demektir. EtherCAT tarafında ETG'nin Conformance Test Tool'u ve akredite test laboratuvarları, PROFINET tarafında PI'ın test laboratuvarı süreci, CANopen tarafında CiA'nın uygunluk testi vardır. Modbus TCP'de zorunlu bir rejim yoktur.

Yük yalnızca test ücreti değildir: cihaz tanım dosyasının doğrulanması, her firmware sürümünde testin tekrarı ve yığının lisans modeli — ticari bir stack mi, IgH gibi açık kaynak bir master mı — takvimi birlikte belirler.

Eleme soruları

Soruları sırayla sorun. Her biri en az bir adayı düşürmek için yazılmıştır; bir soru hiçbir adayı düşürmüyorsa sizin projeniz için ayırt edici değildir, atlayın.

1. Aynı anda koordine edilmesi gereken eksen var mı? Varsa ortak saat tabanı olmayan her aday düşer; Modbus TCP ve klasik CANopen bu adımda elenir.
2. Hedef çevrim süresi milisaniyenin altında mı? Evetse genel amaçlı TCP/IP yığını üzerinden istek/yanıt yapan her şey düşer.
3. Cihaz başına süreç verisi × cihaz sayısı tek çerçeveye sığıyor mu? Sığmıyorsa ya çok çerçeveli çalışmayı kabul edin ya da hedef çevrimi gevşetin. Bu adımda değişen protokol değil, gereksinimdir.
4. Kablolama zaten var mı? Mevcut iki telli hat CAN'ı, mevcut yapılandırılmış kablolama Ethernet tabanlı adayları öne alır. Yeni kanal çekme maliyeti, protokoller arasındaki teknik farkı çoğu zaman siler.
5. Güvenlik fonksiyonları aynı ağdan geçecek mi? Geçecekse güvenlik profili olmayan adaylar düşer.
6. Nihai müşteri hangi kontrolör ailesini kullanıyor? Fabrika standardı bir PLC ailesiyse, o ailenin birinci sınıf desteklediği protokolün dışındaki her seçim entegrasyon maliyeti üretir. Bu teknik değil ticari bir eleme adımıdır ve gerekçesi açıkça yazılmalıdır.
7. Bu makineye on yıl kim bakacak? Sahadaki ekibin hangi devreye alma aletini kullanmayı bildiği, tabloya girmeyen ama kararı gerçekten belirleyen eksendir.
8. Cihaz mı üretiyorsunuz, makine mi kuruyorsunuz? Cihaz üretiyorsanız uygunluk testi yükü birinci sıraya çıkar; makine kuruyorsanız cihaz bulunabilirliği öne geçer.

Brownfield: karar vermeden önce hatta ne olduğunu görün

Mevcut bir tesiste protokol tartışması çoğu zaman hatta gerçekte ne koştuğunu kimsenin bilmemesiyle başlar. Toplantıdan önceki iş, dokümanı değil trafiği okumaktır. Ethernet tabanlı endüstriyel protokoller kendilerini EtherType ile ele verir:

# Hangi endüstriyel protokoller hatta canlı? EtherType'a göre ayır.
sudo tcpdump -i eth0 -e -c 200 'ether proto 0x88a4'   # EtherCAT
sudo tcpdump -i eth0 -e -c 200 'ether proto 0x8892'   # PROFINET RT
sudo tcpdump -i eth0 -e -c 200 'ether proto 0x88f7'   # PTP / IEEE 1588
sudo tcpdump -i eth0 -e -c 200 'ether proto 0x88cc'   # LLDP (topoloji keşfi)
sudo tcpdump -i eth0 -c 200 'tcp port 502'            # Modbus TCP

# CAN tarafı: arayüzü FD kipinde aç, ham trafiği zaman damgasıyla izle
ip link set can0 up type can bitrate 500000 dbitrate 2000000 fd on
candump -td -x can0

# IgH EtherCAT master kuruluysa hattın gerçek envanteri
ethercat master
ethercat slaves

LLDP satırı özellikle işe yarar: yönetilebilir anahtarlar ve PROFINET cihazlarının çoğu komşuluk bilgisini LLDP ile yayınlar. Topoloji çizimini doğrulamanın en ucuz yolu budur; çizimle gerçeğin ayrıştığı yer genelde kararı değiştiren yerdir.

TSN'i doğru katmana koyun

TSN'i bir aday olarak listeye yazmak yaygın bir kategori hatasıdır. Doğru soru "TSN mi EtherCAT mi" değil, "hangi uygulama protokolünü hangi TSN özellikleriyle taşıyacağım" sorusudur. Pratikte üç özellik ayrı ayrı satın alınır ve ayrı ayrı yapılandırılır:

• IEEE 802.1AS — ortak saat. Linux tarafında linuxptp ile kurulur; gPTP profili genel PTP kullanımından farklıdır.
• IEEE 802.1Qbv — zaman farkındalıklı kapı planı. Linux'ta tc altındaki taprio niteleyicisiyle ifade edilir.
• IEEE 802.1Qbu ile 802.3br — çerçeve önceliklendirme. Uzun bir best-effort çerçevesinin planlı pencereyi kaçırmasını engeller.

Standardın kendi gerektirdiği ayarlar, genel PTP varsayılanlarıyla aynı değildir:

# gPTP (IEEE 802.1AS) için ptp4l yapılandırmasının belirleyici satırları
[global]
network_transport   L2
delay_mechanism     P2P
transportSpecific   0x1
ptp_dst_mac         01:80:C2:00:00:0E
logSyncInterval     -3

Bu satırlardan biri genel varsayılanda kalırsa cihaz senkronize olmaz — hata da vermez, sadece komşusunu hiç görmez. Seçim aşamasında bilinmesi gereken şudur: TSN kararı, ağ ekibine yeni bir işletim yükü devretme kararıdır.

Nerede yanlış gider

Tipik çevrim süresine bakarak seçmek. Bir protokolün tipik çevrim süresi ürün sayfasında yazar; sizi ilgilendiren en kötü durumdur. Karar, en kötü durumun sınırlanabilir olup olmadığına göre verilir. Ortalamanın tek başına neden güvence olmadığını ölçüm metodolojimizde ayrıntılandırmıştık.

Senkron hatasını min–maks aralığıyla karıştırmak. Bir ölçüm boyunca görülen en düşük ve en yüksek gidiş-dönüş süresi arasındaki fark, cihazlar arası senkron hatası değildir. İki üreticinin sayısını karşılaştırmadan önce ikisinin aynı şeyi ölçtüğünden emin olun.

Cihaz tanım dosyasını firmware'den bağımsız sürümlemek. ESI, GSDML ve EDS dosyaları cihazın sözleşmesidir. Firmware güncellenip tanım dosyası güncellenmediğinde hata devreye almada değil, aylar sonra eksik bir nesneye erişildiğinde patlar. İkisini aynı depoda, aynı etiketle sürümleyin.

"CAN FD alalım, mevcut CANopen üstünde nasılsa koşar" varsayımı. Klasik CANopen PDO'ları 8 baytla eşlenir; 64 baytlık PDO için CANopen FD (CiA 1301) gerekir ve bu ayrı bir ekosistemdir. Üstelik aynı segmentte FD tolere etmeyen tek bir düğüm bile hata çerçevesi üretir.

Konfigürasyon kanalını kontrol döngüsünde kullanmak. CANopen'da SDO ile, Modbus'ta uzun register bloklarının döngü içinde okunmasıyla aynı hata yapılır. Boot aşamasında konfigüre edin, çalışma anında yalnızca süreç verisi akıtın.

Yönetilmeyen anahtar takmak. EtherCAT hattının ortasına sıradan bir anahtar koymak hattı bozar; PROFINET IRT ve TSN planlı trafik ise anahtarın protokolü desteklemesini şart koşar. "Ethernet konnektörü var, demek ki Ethernet" varsayımı bu üç durumda da yanlıştır ve devreye almada değil, yük altında ortaya çıkar.

Uygunluk terimlerini gevşek kullanmak. Bir protokolün güvenlik profili olması sistemi güvenli yapmaz; bir yığının test aracından geçmesi ürünü belgeli yapmaz. Bu ayrımı teknik şartnameye taşımak, sonradan yapılacak en pahalı düzeltmeyi baştan önler.

Karar kriteri

Kararı bir tabloda değil bir kayıtta bitirin. Aşağıdaki künye projede dosya olarak yaşar; tartışma altı ay sonra yeniden açıldığında baştan başlamak yerine hangi satırın değiştiği konuşulur. Değerler örnektir — künyenin işlevi sayı taşımak değil, hangi soruların cevaplandığını sabitlemektir.

[gereksinim]
koordineli_eksen      = var, 4 eksen
hedef_cevrim          = alt milisaniye
senkron_ihtiyaci      = eksenler arasi ortak saat gerekli
cihaz_sayisi          = 18
cihaz_basina_veri     = giris ve cikis, sabit boyut
topoloji              = hat + iki dal
kablolama             = yeni tesis, kanal serbest
guvenlik_ayni_agda    = evet
musteri_plc_ailesi    = belirtilmedi
urun_tipi             = makine (cihaz uygunluk testi kapsam disi)

[eleme]
adim1_ortak_saat      = Modbus TCP elendi, klasik CANopen elendi
adim2_cevrim          = genel TCP/IP istek-yanit elendi
adim5_guvenlik        = guvenlik profili olmayan adaylar elendi
ayakta_kalan          = EtherCAT, PROFINET IRT

[karar]
secim                 = ekosistem eksenine gore verilecek
gerekce               = teknik eleme iki aday birakti; karar cihaz
                        bulunabilirligi ve saha destegiyle netlesecek
yeniden_degerlendirme = cihaz sayisi iki katina cikarsa veya guvenlik
                        fonksiyonlari ayri kabloya alinirsa

Pratik kural üç cümleye sığar. Bir: koordineli hareket varsa ortak saat tabanı olmayan hiçbir adayı listede tutmayın — bu eksende esneklik yoktur. İki: teknik eleme tek aday bırakmıyorsa kararı ekosistem verir; cihaz bulunabilirliği, müşterinin kontrolör ailesi ve sahadaki bilgi bu kararın gerekçesidir ve yazılı olmalıdır. Üç: kararla birlikte onu geçersiz kılacak eşiği de yazın. Eşiği olmayan bir karar kayıt değil, sadece bir tercihtir.