TSN: Endüstriyel Ağda Zaman Hassas Haberleşmenin Mimarisi

Sorunu doğru tarif etmek

Endüstriyel bir hücrede tek kablo üzerinde birbirine benzemeyen üç trafik akar: eksen komutları (küçük, periyodik, dar bütçeli), görü akışı (patlamalı, yüksek hacimli) ve mühendislik trafiği (log, güncelleme, uzak erişim). Klasik Ethernet bu üçünü aynı çıkış kuyruğunda değerlendirir. Bir anahtarın portunda 1500 baytlık bir güncelleme paketi iletilmeye başladıysa, arkasından gelen eksen komutu onun bitmesini bekler — ve bu bekleme sabit değildir. Yani sorun bant genişliği değil, kuyruk gecikmesinin dağılımıdır.

Endüstriyel protokollerin klasik cevabı sorundan kaçmaktı: ayrı bir fiziksel ağ kur, üzerinde yalnızca kontrol trafiği koşsun. EtherCAT, PROFINET IRT ve SERCOS III bu yaklaşımın ürünleridir ve işlerini yaparlar. IEEE 802.1 TSN çalışma grubunun önerisi farklıdır: ayrı ağ kurmak yerine standart köprünün içine zamanı sokmak.

Bu yazı, hangi alt standardın hangi sorunu çözdüğünü, kararın hangi katmanda verildiğini ve EtherCAT'in yerini ne zaman aldığını — ne zaman almadığını — ele alıyor. Yazıda Spikedge tarafından yapılmış bir TSN ölçümü yoktur; geçen bütün sayılar ya standart tanımından ya da kaynağı adıyla verilmiş belgelerden gelir.

TSN tek bir standart değildir

"TSN destekli" ifadesi tek başına hiçbir şey söylemez. TSN bir standart değil, IEEE 802.1Q'ya eklenmiş bir dizi ayrı mekanizmadır; bir anahtar bunlardan yalnızca birini destekleyip etikete hak kazanabilir. Alım kararının ilk adımı, hangi mekanizmanın gerektiğini adlandırmaktır.

Endüstriyel bağlamda buna iki şey daha eklenir: veri modelini NETCONF üzerinden taşıyan YANG modülleri (IEEE 802.1Qcp ve 802.1Qcw) ve hangi alt kümenin otomasyon için zorunlu olduğunu belirlemeye çalışan IEC/IEEE 60802 TSN Profili. 60802 hâlâ geliştirme aşamasındadır; "60802 uyumlu" diyen bir tedarikçiye hangi taslak sürümüne göre olduğu sorulmalıdır.

Qav ve Qbv aynı işi yapmaz

Sahada en çok karıştırılan iki mekanizma bunlardır; karışıklığın bedeli yanlış donanım alımıdır.

802.1Qav (CBS) bir bant paylaştırıcısıdır. Her sınıfın bir kredi sayacı vardır: sınıf beklerken kredi idleslope hızıyla artar, iletirken sendslope hızıyla azalır, kredi negatifken sınıf iletemez. CBS ortalama davranışı düzenler; belirli bir çerçevenin belirli bir anda hatta çıkacağını söylemez.

802.1Qbv (TAS) bir takvimdir. Port üzerinde bir çevrim süresi ve onu bölen bir kapı kontrol listesi (GCL) tanımlanır; her giriş, hangi kuyrukların kapısının ne kadar açık kalacağını bit maskesiyle söyler. Kontrol trafiğine ayrılmış pencerede diğer bütün kapılar kapalıdır — o pencerede hattı paylaşacak kimse yoktur. Qbv belirli bir anı garanti eder, karşılığında bütün ağdan ortak saat ve ortak takvim ister.

Pratik sonuç: "video akışı diğer trafiği boğmasın" derdiniz varsa Qav yeter ve kurulumu çok daha ucuzdur. "Bu komut her çevrimde şu pencerede hatta çıksın" diyorsanız Qbv gerekir — ve beraberinde 802.1AS zaman alanını, GCL yönetimini ve koruma bandı hesabını da satın alırsınız.

Koruma bandı: Qbv'nin gizli maliyeti

Zaman kapılı bir pencere açılmadan önce hattın boş olduğundan emin olunmalıdır; aksi halde pencere açıldığında hâlâ iletilmekte olan bir best-effort çerçevesi kritik çerçevenin başlangıcını geciktirir. Köprü bu yüzden pencerenin önüne bir koruma bandı koyar: o süre boyunca yeni çerçeve başlatılmaz.

Bandın boyu, tanım gereği, o portta başlayabilecek en uzun çerçevenin hat üzerindeki süresidir. IEEE 802.3'e göre etiketsiz azami çerçeve 1518 bayt, 802.1Q VLAN etiketiyle 1522 bayttır; buna 8 baytlık önsöz/SFD ve 12 baytlık çerçeveler arası boşluk eklenir — 1542 bayt, yani 12336 bit. 1 Gbit/s'te bu 12,336 mikrosaniye, 100 Mbit/s'te 123,36 mikrosaniyedir. Çevrimi 1 ms olan bir tasarımda 100 Mbit/s hat, çevrimin yaklaşık sekizde birini hiçbir işe yaramayan bir bekleyişe harcar.

802.1Qbu ile 802.3br'nin birlikte tarif ettiği çerçeve önceliklendirme tam olarak bu maliyeti düşürür: iletilmekte olan çerçeve bölünür, acil çerçeve araya girer. 802.3br bölünen parçalar için asgari boyutu belirler — addFragSize parametresi 0–3 değerlerini alır, sırasıyla 64, 128, 192 ve 256 bayt. Koruma bandı böylece azami çerçeve süresinden en küçük parçanın tamamlanma süresine iner. Bu, Qbu'yu dar çevrimli tasarımlarda "isteğe bağlı ek" değil pratik bir gereklilik yapar.

Hangi katmanda kim karar veriyor

TSN tartışmalarının çoğu, kararın nerede alındığı netleşmediği için tıkanır. Üç ayrı sorumluluk vardır ve üçü farklı ekiplere aittir.

Bu üçünün birbirini tanımaması en sık görülen başarısızlık biçimidir: uç nokta çerçeveyi doğru anda üretir ama önceliği yanlış işaretler; köprünün takvimi doğrudur ama uç noktanınkiyle hizalı değildir; yapılandırma düzlemi yoktur, herkes kendi cihazını elle ayarlamıştır ve toplamın doğruluğunu kimse doğrulayamaz.

IEEE 802.1Qcc bunu üç modelle adlandırır: tamamen dağıtık, merkezi ağ yapılandırması (CNC) ve tamamen merkezi (CNC + CUC). Endüstriyel bir hücrede pratik olan genellikle ikincisidir; birincisi ölçeklenmez, üçüncüsü uç nokta tarafında ciddi yazılım yatırımı ister.

Linux tarafındaki karşılığı

Uç nokta tarafı Linux'ta üç ayrı tc sıralayıcısıyla karşılanır. Çekirdekte CONFIG_NET_SCH_TAPRIO, CONFIG_NET_SCH_CBS, CONFIG_NET_SCH_ETF, CONFIG_NET_SCH_MQPRIO ve donanım zaman damgası için CONFIG_PTP_1588_CLOCK açık olmalıdır.

Önce zaman alanı kurulur. 802.1AS profili linuxptp'nin gPTP.cfg dosyasıyla gelir; profili genel IEEE 1588'den ayıran alanlar şunlardır:

[global]
transportSpecific       0x1
ptp_dst_mac             01:80:C2:00:00:0E
network_transport       L2
delay_mechanism         P2P
time_stamping           hardware
logSyncInterval         -3
path_trace_enabled      1
follow_up_info          1

transportSpecific 0x1, 01:80:C2:00:00:0E hedef adresi ve P2P gecikme mekanizması 802.1AS'e özgüdür; logSyncInterval -3 standardın öngördüğü 125 ms senkronizasyon aralığına karşılık gelir. Servis ptp4l ile koşar, PHC ile sistem saati arasındaki bağı phc2sys kurar.

Takvimi yazmadan önce donanımın gerçekte ne desteklediği doğrulanır — ethtool -T eth0 zaman damgası yeteneklerini, ethtool -l eth0 gerçek donanım kuyruk sayısını verir. Ardından 1 ms çevrimli, üç sınıflı bir takvim şöyle tanımlanır:

tc qdisc replace dev eth0 parent root handle 100 taprio \
    num_tc 3 \
    map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
    queues 1@0 1@1 1@2 \
    base-time 1600000000000000 \
    sched-entry S 01 300000 \
    sched-entry S 02 300000 \
    sched-entry S 04 400000 \
    flags 0x2

tc qdisc replace dev eth0 parent 100:1 etf \
    clockid CLOCK_TAI delta 500000 offload

tc qdisc replace dev eth0 parent 100:2 cbs \
    idleslope 20000 sendslope -980000 hicredit 30 locredit -1470 offload 1

Üç ayrıntı kritiktir. map alanı, SO_PRIORITY soket seçeneğiyle işaretlenmiş öncelikleri trafik sınıflarına eşler; uygulama bu çağrıyı yapmıyorsa bütün trafik varsayılan sınıfa düşer. base-time ve etf clockid CLOCK_TAI tabanındadır, uygulamanın alıştığı CLOCK_REALTIME değil. flags 0x2 tam donanım boşaltması ister — 0x1 yalnızca gönderim zamanı yardımı, 0x0 ise saf yazılım demektir ve yazılım kipinde takvim, Linux zamanlayıcısının en kötü durumuna tabidir.

Uygulama tarafında çerçevenin çıkış anını SO_TXTIME soket seçeneği ve gönderimle iletilen SCM_TXTIME kontrol mesajı belirler. Sürücü desteği tek tek kontrol edilmelidir: Intel igb/igc, Synopsys tabanlı stmmac ve TI'nin am65-cpsw sürücüsü bu yolun farklı parçalarını farklı olgunlukta destekler.

EtherCAT ile rakip mi, tamamlayıcı mı?

İki teknoloji aynı sorunu farklı yerden çözdüğü için tek cümlelik cevap yoktur.

EtherCAT (IEC 61158 Type 12) standart Ethernet çerçevesi kullanır ama içindeki modeli değiştirir: çerçeve mantıksal bir halka üzerinde dolaşır, her slave onu geçerken işler, kendi verisini yazıp devam ettirir. Anahtar yok, kuyruk yok, dolayısıyla kuyruk gecikmesi de yok. Senkronizasyon, Dağıtık Saatler (DC) mekanizmasıyla slave ASIC'lerinin içinde kurulur. Bu mimaride neyin belirleyici olduğunu EtherCAT ölçüm metodolojisi yazımızda somut bir tezgâh üzerinden anlattık.

TSN ise standart köprüyü koruyup içine takvim koyar. Kazanç, aynı fiziksel ağın farklı üreticilerin farklı protokollerini taşıyabilmesidir: OPC UA PubSub (OPC 10000-14) ve OPC UA FX, PROFINET'in TSN sürümü ve düz IP trafiği aynı kablo üzerinde kendi pencerelerinde koşabilir.

Uygulamada en sık görülen üçüncü seçenek ikisini rakip olmaktan çıkarır: TSN omurga, EtherCAT segment. Hücre içindeki eksen kontrolü EtherCAT master'ının arkasında kalır; hücreler arası trafik, hat düzeyi görü ve MES bağlantısı TSN omurgada kendi pencerelerini kullanır. Bu düzende EtherCAT çerçeveleri TSN anahtarından geçmez — master'ın portu segmentin sınırıdır.

Nerede yanlış gider

1. EtherCAT segmentini TSN anahtarından geçirmeye çalışmak. Belirti: "hepsi Ethernet, aynı anahtara takarız." Sonuç: geçerken işleme modeli ve DC senkronizasyonu, store-and-forward bir köprünün arkasında anlamını kaybeder. Segment master portundan başlar, son slave'de biter; ortasına genel amaçlı bir anahtar giremez.

2. Saat alanını karıştırmak. Belirti: takvim doğru görünüyor ama çerçeveler beklenenden çok uzakta bir anda çıkıyor. Sebep: taprio base-time ve etf clockid CLOCK_TAI tabanındayken uygulamanın CLOCK_REALTIME kullanması. TAI ile UTC arasında IERS'in ilan ettiği tam saniyelik bir fark vardır; phc2sys -O ile açıkça verilmezse PHC ile sistem saati arasında sabit bir kayma kalır.

3. Yazılım kipini donanım boşaltması sanmak. Belirti: tc komutu hatasız döndü, takvim "çalışıyor". Gerçek: flags 0x2 desteklenmiyorsa yapılandırma yazılım kipinde kurulur ve determinizm artık NIC'in değil, Linux zamanlayıcısının sözüdür. tc -s qdisc show dev eth0 çıktısı ve sürücünün offload'ı gerçekten kabul edip etmediği ayrıca doğrulanmalıdır.

4. Koruma bandını bütçeye koymamak. Belirti: kâğıt üzerindeki pencere toplamı çevrime sığıyor, sahada sığmıyor. Sebep: her kritik pencerenin önündeki koruma bandı hesaba katılmamıştır. Çerçeve önceliklendirme yoksa bu bant küçültülemez.

5. Zincirdeki tek bir 802.1AS-farkında olmayan cihaz. Belirti: iki uç senkron, aradaki üçüncü sürekli kayıyor. Sebep: yol üzerindeki bir anahtar gPTP mesajlarını sıradan çok noktaya yayın gibi iletir, bekleme süresini (residence time) düzeltmez. Zaman alanı orada kopar ve aşağısındaki bütün takvimler geçersizdir.

6. Öncelik eşleme zincirinin ortasında kopması. Belirti: kritik trafik best-effort kuyruğunda. Zincir uzundur: SO_PRIORITY → skb->priority → taprio/mqprio map alanı → VLAN arayüzünün egress-qos-map ayarı → hattaki PCP biti → köprünün kuyruk eşlemesi. Bir halka eksikse trafik sessizce yanlış kuyruğa düşer; hiçbir hata üretilmez.

7. Best-effort trafiği hiç ölçmemek. Belirti: kritik akış kusursuz, ama mühendislik erişimi kopuyor, güncelleme yarıda kalıyor. Qbv, korumadığı trafiği açlığa itebilir. Doğrulama planında kritik akışın gecikme dağılımı kadar, kritik olmayan trafiğin verimi de bulunmalıdır.

Geçiş yolu

TSN'e geçiş tek bir alım kararı değildir; sıra bozulduğunda her adım bir sonrakini geçersizleştirir.

1. Akış envanteri çıkarın. Kim kiminle, hangi periyotla, hangi çerçeve boyuyla konuşuyor ve teslim tarihi kaçırılırsa ne oluyor. Bu tablo yoksa pencere tahsisi yapılamaz; TSN'in gerçek girdisi budur.
2. Önce zaman alanını kurun. gPTP tek başına, takvim olmadan da değerlidir: bütün düğümler ortak zamana oturduğunda ağ ilk kez ölçülebilir hale gelir. Bu adım aynı zamanda hangi cihazın 802.1AS-farkında olmadığını ortaya çıkarır.
3. Kuyruk ayrımıyla başlayın. Katı öncelik ve gerekirse Qav, envanterdeki sorunların önemli kısmını GCL yönetimine hiç girmeden çözer. Bundan sonra hâlâ kaçırılan teslim tarihi kalıyorsa Qbv gerçekten gereklidir.
4. Qbv'yi yalnızca gereken portlarda açın. Takvim, koştuğu her portun yönetim yükünü artırır. Bütün ağa uygulamak yerine kritik yolu taşıyan portlarla sınırlayın; çerçeve önceliklendirmeyi aynı anda değerlendirin.
5. Yapılandırma düzlemini otomatikleştirin. Elle yazılmış GCL'ler ilk topoloji değişikliğinde dağılır. 802.1Qcc'nin CNC modeli ve YANG/NETCONF veri modelleri bu yüzden vardır.

Karar kriteri

• Tek makine, tek üretici, sıkı senkron eksen kontrolü. EtherCAT'te veya mevcut fieldbus'ta kalın. TSN'in çözdüğü sorun sizde yok; ekleyeceği tek şey yapılandırma yüküdür.
• Farklı üreticilerin, farklı kritiklikteki trafiği tek altyapıda birleşecek. TSN'in asıl gerekçesi budur; akış envanterinden başlayın.
• Hücre içi determinizm + hücreler arası karışık trafik. İkisi rakip değil: TSN omurga, arkasında EtherCAT segmentler. Sınır master portudur.
• Ekipte ağ mühendisliği sahipliği yok. TSN erkendir. Sahipsiz bir kapı kontrol listesi, sahipsiz bir firmware kadar risklidir; ilk topoloji değişikliğinde kimse sonucu doğrulayamaz.
• Tedarikçi "TSN destekli" diyor. Hangi alt standart? Qav mı Qbv mi, Qbu var mı, 802.1AS'te bekleme süresi düzeltmesi yapıyor mu, yapılandırma arayüzü ne? Bu cevaplar tek tek alınmadan o ifade bir yetenek beyanı değildir.

Kararların hiçbiri ölçümsüz kapanmaz. Bir TSN tasarımında yayımlanmaya değer her sayı üç şeyle birlikte anlam kazanır: hangi topolojide, hangi yük altında, hangi yöntemle ölçüldü. Üçünden biri eksikse sayı yayımlanmaz — bu disiplin ölçülen katman değişse de aynı kalır.

Mevcut ağınızda bu geçişin gerekli olup olmadığını tartışmak isterseniz, endüstriyel protokol yetkinliğimiz tam olarak akış envanteri ve sınır çizme sorusuyla başlar; kapsamı birlikte belirlemek için gömülü sistem mimari denetimi planlayabilirsiniz.

Kaynaklar

1. IEEE — IEEE 802.1Q-2022, Bridges and Bridged Networks (Qav, Qbv, Qbu, Qci ve Qch mekanizmalarını içerir) — https://standards.ieee.org/ieee/802.1Q/10323/
2. IEEE — IEEE 802.1AS-2020, Timing and Synchronization for Time-Sensitive Applications — https://standards.ieee.org/ieee/802.1AS/7121/
3. IEEE — IEEE 802.3br-2016, Interspersing Express Traffic — https://standards.ieee.org/ieee/802.3br/5480/
4. IEEE 802.1 TSN Görev Grubu — proje listesi ve durumları — https://1.ieee802.org/tsn/
5. IEC/IEEE — 60802, TSN Profile for Industrial Automation (geliştirme aşamasında) — https://1.ieee802.org/tsn/iec-ieee-60802/
6. Linux kılavuz sayfaları — tc-taprio(8), tc-etf(8), tc-cbs(8) — https://man7.org/linux/man-pages/man8/tc-taprio.8.html
7. linuxptp projesi — gPTP.cfg yapılandırma örneği — https://linuxptp.sourceforge.net/
8. OPC Foundation — OPC 10000-14: PubSub — https://reference.opcfoundation.org/Core/Part14/

Kaynaklara erişim tarihi: 5 Eylül 2026. IEEE standartları düzeltme ve birleştirme alır; alt standartların 802.1Q içindeki madde numaraları sürümden sürüme değişir. Bir tedarikçi beyanını doğrularken hangi sürüme dayandığını açıkça sorun.