Substation automation’da SCL (CID, SED, ICD) mühendisliği: dosyadan devreye almaya

Bir alt istasyon otomasyonu projesinde her şey kablo ve panoyla başlıyormuş gibi görünür. Sahada ilk paket yakalama dosyasını açtığınız anda gerçeği görürsünüz: işi taşıyan omurga SCL’dir. IEC61850 dünyasında bir sinyalin adı, yeri, nasıl raporlanacağı, kime GOOSE ile gideceği ve hangi ağdan akacağı, çoğu zaman bir SCL dosyasının doğru kurgulanmasına bağlıdır.

Peki bir ICD, SED veya CID dosyasını elinize aldığınızda, bunu devreye almaya kadar nasıl güvenle götürürsünüz? Tipik sorunlar tanıdık gelir: uyumsuz veri modeli, yanlış GOOSE hedefi, eksik raporlama blokları, yanlış VLAN veya zaman senkronu sapmaları.

Bu yazı, dosyadan başlayıp doğru konfigürasyonla devreye almaya giden uçtan uca akışı netleştirir. Ayrıca pratik kontrol noktaları, sahada zamanı yakan hatalar ve hızlı teşhis ipuçları da içerir.

IEC61850 ve SCL’yi sahadaki işleri kolaylaştıracak şekilde anlamak

IEC61850, sadece “Ethernet üzerinden haberleşme” demek değildir. Bir alt istasyonda koruma, kontrol, ölçü ve izlemeyi ortak bir modelle konuşur hale getirir. Bu modelin sahaya yansıyan adı ise SCL’dir (Substation Configuration Language). SCL’yi, projenin ortak dili gibi düşünebilirsiniz. Aynı dili konuştuğunuzda, üretici farkı azalır, testler kısalır, sürprizler azalır.

SCL’nin en güçlü tarafı, tek bir yerden gerçeği taşıma iddiasıdır. Yani “tek kaynak” mantığına yaklaşır: hangi Logical Node (LN) var, hangi DataSet yayınlanıyor, hangi ReportControl aktif, GOOSE’un APPID’si ne, MAC adresi hangi aralıkta, hepsi bir tasarım disiplinine bağlanabilir. Bu disiplin yoksa, sahada pahalı sonuçlar çıkar. Çünkü sahada kaybedilen dakika, çoğu zaman ekipman kiralaması, enerji kesintisi penceresi ve test ekibi beklemesi demektir.

Dosya tipleri burada devreye girer. ICD, IED’nin yetenek beyanıdır. SED, istasyon seviyesindeki tasarımın ve haberleşme kurgusunun derlenmiş halidir. CID ise “bu IED bu projede böyle çalışacak” diye cihazın içine yüklenen, hedefe özel konfigürasyondur. Bu akış doğru kurulursa devreye alma, karanlıkta el yordamıyla değil, haritayla yürümeye benzer.

IEC61850’e yeni başlayanlar için temel kavramları toparlayan bir kaynak olarak şu sayfa yardımcı olabilir: IEC61850 protokolü ve alt istasyon otomasyonu hakkında temel bilgiler. Ancak sahada fark yaratan şey, tanımdan çok uygulama disiplinidir.

ICD, CID, SED farkı: kim üretir, kim tüketir, ne zaman kilit olur

Aynı projede üç dosya tipi aynı anda dolaşır, karışması normaldir. En pratik ayrım, “kim üretir, kim kullanır, hangi anda kilit olur?” sorularıyla yapılır.

Kısa bir senaryo düşünelim: Bir koruma rölesi (IED-1), bir bay kontrol ünitesi (IED-2), bir istasyon HMI/SCADA (istemci). Koruma rölesinin ICD’si size “hangi LN’ler var, hangi raporları destekler, GOOSE yayınlayabilir mi?” sorularının cevabını verir. Bay kontrol ünitesinin ICD’si de aynı şekilde kabiliyetini anlatır.

Sonra SED ile istasyonun haberleşme tasarımını kurgularsınız: Koruma rölesinin XCBR durumunu GOOSE ile bay kontrol ünitesi alsın, ayrıca arıza göstergeleri raporlarla SCADA’ya gitsin gibi. En son, her IED için CID üretirsiniz. Koruma rölesinin CID’si ile bay kontrol ünitesinin CID’si, aynı proje içinde bile farklı olur, çünkü hedef cihaz, IP, VLAN, DataSet içeriği ve abonelik listesi değişir.

SCL içindeki temel taşlar: veri modeli, iletişim ve raporlama parçaları

SCL dosyası açıldığında göz korkutabilir. Sahada işi hızlandıran yaklaşım, “hangi parçaya bakarsam hangi testi kolaylaştırırım?” diye düşünmektir.

IED ve AccessPoint, cihazın kimliği ve haberleşme kapısıdır. Yanlış AccessPoint seçimi, doğru CID yükleseniz bile bağlantıyı boşa çıkarabilir. Özellikle bir cihazda birden fazla Ethernet portu veya farklı erişim noktaları varsa, sahada “IP doğru ama bağlanmıyor” şikayeti buradan çıkabilir.

LDevice, LN (Logical Node) kısmı, veri modelinin evidir. Sinyal isimleri, instanslar ve fonksiyonlar burada yaşar. Sahada bir sinyalin karşılığını bulmak için, “bu ölçüm hangi LN’de, hangi Data Object’te?” sorusuna net cevap gerekir. LN instans isimleri tutarsızsa, eşleme ve test uzar.

DataSet, hem GOOSE hem raporlama tarafında “hangi veriler paketlenecek?” sorusunun cevabıdır. DataSet’i doğru kurarsanız, sahadaki test planı netleşir. Yanlış kurarsanız, test ekibi doğru sinyali ararken saat kaybeder.

GSEControl (GOOSE), hızlı olay iletiminde merkezdir. Burada yayın adı, APPID, MAC, VLAN ve tekrar parametreleri sahaya yansır. Yanlış VLAN veya APPID, sahada “paket var ama abone almıyor” vakasına dönüşür.

ReportControl, SCADA istemcisine giden raporların kalbidir. Buffered mı Unbuffered mı, tetik koşulları (Trigger Options), Integrity Period gibi kararlar, devreye alma sırasında “olay geldi mi, kaçırdı mı, tampon doldu mu?” sorularını belirler.

Sampled Values (kullanılıyorsa), özellikle proses bus mimarisinde ayrı bir dünya açar. Bu yazının odağı değil, ama şunu bilmek yeter: SV varsayımıyla yapılan bir ağ tasarımı, zaman senkronu ve bant genişliği hatalarını affetmez.

Dosyadan konfigürasyona: CID, SED ve ICD üzerinde adım adım mühendislik akışı

SCL mühendisliğini “dosya editöründe birkaç alan doldurmak” gibi görmek en hızlı hataya giden yoldur. Sağlam bir akış, sahada sürprizleri azaltır ve devreye alma süresini kısaltır. Buradaki amaç, tek seferde kusursuz olmak değil, değişikliği yönetilebilir kılmaktır.

İlk adım gereksinim toplama ve standart kararlardır. İsimlendirme kuralı (naming convention) belirlenmeden başlanırsa, aynı sinyalin üç farklı adı olur. Bir ekip “XCBR1.Pos.stVal” der, diğeri “CB1_Status” diye not düşer, üçüncüsü SCADA tag’ine başka bir isim verir. Sonra arıza anında herkes başka bir şeyi arar.

Ardından ağ planı gelir: IP planı, VLAN tasarımı, gerekliyse PRP/HSR gibi yedeklilik yaklaşımı, port hızları ve multicast yönetimi. GOOSE trafiği, iyi tasarlanmamış bir ağda sessizce büyür ve test günü paket kaybı gibi görünür. Oysa çoğu zaman sorun, en baştaki topoloji ve parametre kararlarıdır.

Sonra IED şablonları (template) mantığıyla ilerlemek işe yarar. Aynı tip röleler, aynı tip bay kontrol üniteleri benzer rapor blokları ve DataSet yapılarıyla yönetilirse, CID üretimi daha tutarlı olur. Burada SED tasarımı devreye girer. SED, istasyon seviyesindeki bağları görünür kılar: kim kime GOOSE atıyor, hangi DataSet’ler kullanılıyor, hangi raporlar hangi istemciye gidiyor.

Son adım, CID üretimi, sürümleme ve değişiklik yönetimidir. CID’yi e-posta eki olarak dolaştırmak, devreye almada “hangi dosya yüklü?” sorusunu kabusa çevirir. Basit bir sürüm numarası, değişiklik kaydı ve dosya imza mantığı bile ciddi fark yaratır. Özellikle sahada bir IED değiştiğinde, yeni donanım revizyonunun aynı CID ile çalışıp çalışmayacağını önden bilmek istersiniz.

Ön hazırlık: tek çizimden çok, doğru veri listesi gerekir

Tek hat şeması çoğu şeyi anlatır, ama SCL için tek başına yetmez. Konfigürasyonu besleyen doğru listeler yoksa, SED ve CID üretimi eksik kalır.

İhtiyaç duyulan girdiler genelde şunlardır: sinyal listesi (durumlar, alarmlar, kumandalar, ölçüler), fonksiyon listesi (koruma fonksiyonları, kilitlemeler, otomatik tekrar kapama gibi), bay yapısı, olay kayıt ve raporlama ihtiyaçları, zaman senkronu yaklaşımı (SNTP mi, PTP mi). Ayrıca SCADA tarafının neyi nasıl görmek istediği, rapor tetik koşullarını doğrudan etkiler.

Bu noktada birkaç kritik karar, ilerideki test süresini belirler. Örneğin bir rapor için tetik koşullarını çok geniş seçerseniz, SCADA tarafında gereksiz trafik oluşur, tamponlar dolar. Çok dar seçerseniz, operatör aradığı olayı göremez. GOOSE yayın ve abonelik sınırları da benzer bir denge ister. Her şeyi GOOSE ile taşımak hızlı görünür, ama yönetimi zorlaşır. Her şeyi rapora bırakmak da gecikme ve sunucu yükü oluşturabilir.

Basit bir ilişki kurmak işe yarar: Girdi eksikse sonuç da eksik olur. Ölçü listesi net değilse, DataSet yanlış kurulur. Zaman senkronu kararı net değilse, arıza kayıtları karşılaştırılamaz. İsimlendirme kuralı yoksa, test tutanakları bile karışır.

CID üretimi ve yükleme: aynı dosya herkes için aynı mı

CID, “herkese uyan tek dosya” değildir. Tam tersine, CID hedef IED’ye özeldir. Aynı ICD’den, aynı proje içinde birden fazla CID çıkabilir. Çünkü her cihazın rolü farklıdır, abonelik listesi farklıdır, ağ parametreleri farklıdır.

Akış genelde şöyle ilerler:

1. ICD ve/veya SED dosyalarını sistem konfigürasyon aracına içe aktarın (import).
2. İstasyon yapısını ve isimlendirmeyi oturtun, veri eşlemelerini yapın (mapping).
3. DataSet’leri oluşturun veya doğrulayın, GOOSE ve ReportControl bağlarını kurun.
4. Hedef IED için CID’yi dışa aktarın (export) ve sürümleyin.
5. Cihaza yükleyin, cihaz üzerinde aktif edin, gerekiyorsa yeniden başlatın.
6. Yükleme sonrası cihazdan geri okuma veya doğrulama yapın (mümkünse).

Sahada en sık çıkan hatalar, küçük ama öldürücü detaylardır: yanlış VLAN ID, yanlış multicast MAC, yanlış APPID, yanlış GoID, hatta yanlış AccessPoint. Bir CID doğru görünür, ama yanlış VLAN yüzünden paketler hiç ulaşmaz. Ya da APPID çakışır, farklı yayınlar birbirine karışır. Bu yüzden CID üretimini “dosya üret” adımı değil, “ağ ve servis bütünlüğünü kilitle” adımı olarak görmek gerekir.

Devreye alma aşamasında SCL doğrulama ve test planı

Devreye alma sırasında iyi bir test planı, SCL’nin kontrol noktalarıyla eşleştiğinde hız kazanır. Aksi halde ekip, sahada semptomla uğraşır, kök neden dosyanın içindedir.

Başlangıç testleri ağdan başlar: IP erişimi, VLAN geçişi, multicast davranışı, gerekliyse yedeklilik mekanizmasının çalışması. Burada SCL tarafında IED iletişim tanımları, GOOSE parametreleri ve istemci bağlantı bilgileriyle sahadaki ölçüm aynı dili konuşmalıdır. Paket yakalama aracıyla GOOSE paketini görüp, SCL’deki APPID ve MAC ile eşleştirmek, en hızlı doğrulamalardan biridir.

Zaman senkronu testi de SCL ile dolaylı bağlıdır, ama etkisi büyüktür. PTP kullanılıyorsa domain ayarı ve master seçimi, SNTP kullanılıyorsa sunucu adresleri ve güncelleme aralığı; hepsi olay kayıtlarının güvenilirliğini belirler. Bir arıza sonrası kayıtları yan yana koyduğunuzda zamanlar kayıyorsa, sorun çoğu zaman “sinyal yanlış” değil, saat yanlıştır.

Raporlama testlerinde, SCL’deki ReportControl ayarları ile SCADA istemcisinin aboneliği birlikte düşünülmelidir. Buffered rapor, bağlantı kesilse bile tampon sayesinde veriyi korur, ama tampon dolarsa veri düşebilir. Unbuffered rapor daha basittir, ama kısa kopmalarda veri kaybı yaşanır. Bu tercihler, devreye alma testinde özellikle görülür.

GOOSE ve raporlama testleri: doğru sinyal, doğru hedef, doğru zaman

GOOSE testinde amaç, “paket var” demek değil, doğru paketin doğru hedefe doğru sürede gitmesini kanıtlamaktır. Uygulanabilir kısa bir sıra şöyle olabilir:

1. Yayıncı IED’de ilgili DataSet içeriğini doğrulayın, sahada tetikleyeceğiniz sinyali seçin.
2. Paket yakalama ile GOOSE’u izleyin, stNum ve sqNum davranışını kontrol edin (olayda stNum artmalı, tekrarlarla sqNum akmalı).
3. tALIVE ve tekrar aralıklarının beklenen şekilde çalıştığını gözleyin, kalite bitlerinin (quality) normal olduğunu teyit edin.
4. Abone IED’de ilgili girişlerin eşlendiğini ve mantıkta kullanıldığını gösterin (örneğin bir kilitleme veya alarm).
5. VLAN, MAC ve APPID değerlerini SCL ile birebir eşleştirin.

Raporlama testinde, Buffered ve Unbuffered ayrımını bilmek işleri netleştirir. Trigger Options ve Integrity Period ayarları, “olay geldi mi?” sorusunun teknik cevabıdır. En pratik yaklaşım, bir durum değişimi tetikleyip raporun istemciye düşmesini izlemek, sonra bağlantıyı kısa süre kesip buffered raporun telafi edip etmediğini kontrol etmektir.

Sahada en çok görülen konfigürasyon hataları ve hızlı teşhis ipuçları

• Veri modeli uyuşmazlığı: Belirti, SCADA’da beklenen veri yolunun bulunmaması; kontrol, SCL’de LN ve Data Object yolunu ve üretici ICD sürümünü karşılaştırın.
• LN instans isimleri tutarsızlığı: Belirti, eşleme ekranında benzer sinyallerin karışması; kontrol, LDevice içindeki LN adlandırmasını proje standardıyla doğrulayın.
• Yanlış FCDA seçimi: Belirti, DataSet dolu görünür ama değerler değişmez; kontrol, FC (ST, MX, CO) alanının doğru seçildiğini SCL’de inceleyin.
• Eksik DataSet veya yanlış içerik: Belirti, GOOSE geliyor ama kritik bit yok; kontrol, DataSet üyelerini ve hangi sinyallerin test edileceğini listeyle eşleştirin.
• Yanlış IP/VLAN: Belirti, aynı switch içinde bile abone alamaz; kontrol, SCL iletişim parametrelerini ve switch yapılandırmasını yan yana koyun.
• PTP domain hatası: Belirti, saat var gibi görünür ama kayar; kontrol, PTP domain ve master seçimini cihaz ayarlarından doğrulayın.
• Rapor tamponunun dolması: Belirti, olaylar aralıklı kaybolur; kontrol, Buffered rapor ayarlarını, tampon boyutunu ve istemci bağlantı sürekliliğini kontrol edin.

SCL’yi doğru yönetmek, devreye almayı kısaltır

IEC61850 projelerinde SCL, konfigürasyonun omurgasıdır. ICD, SED ve CID dosyalarını doğru akışla yönetirseniz, devreye alma daha hızlı ilerler, sahadaki riskler azalır, testler daha net olur. En iyi sonuç, “sahada deneriz” yaklaşımıyla değil, masa başında doğrulanmış bir tasarımla gelir.

Pratik bir eylem listesiyle bitirelim: standart isimlendirmeyi en başta kilitleyin, CID dosyalarını sürümleyin, SCL doğrulama kontrol listesi oluşturun, sahaya gitmeden GOOSE ve raporlamayı masa başında senaryolaştırın. Devreye alma günü geldiğinde hedef basittir: dosyadaki tasarım, sahada aynı davranışı versin. Bu eşleşmeyi kurduğunuzda, işler gerçekten yoluna girer.