MakinaTek dergisi, Türkiye makina imalat sektörünün gelişimine ve büyümesine katkı sağlamayı ana misyonu olarak görmekte ve sektörün gelişen profilini sergilemeyi amaçlamaktadır.

SCADA İle Cihazlar Arası Veri Yönetiminde “Push-Tipi” Kolaylık ve Verim

GSL

Yarım yüzyıldan daha uzun süredir SCADA sistemleri, merkezi bir kontrol odasında bulunan operatörlere, geniş bir coğrafyaya yayılmış çok sayıda cihazı denetleme ve kontrol edebilme olanağı tanıyor.

Modern bir SCADA sisteminin yapısında, Şekil 1’de de görüldüğü üzere, üstte SCADA yazılımı, altta takip edilen cihazlar ve ikisinin arasında bir OPC sunucusu bulunur. PLC, RTU ve/veya uzak I/O modülleri (Moxa’nın ioLogik serisi örnek verilebilir), sensör değerlerini ve kontrol sinyallerini OPC sunucusu ve cihazlar arasında aktarmada kullanılır. PLC, RTU ve/veya I/O modüller uzak sahalara belirli ölçüde özerklik kazandırır ve yerel kontrol planlarını SCADA yazılımından bağımsız olarak uygulamaya koyabilecek kadar da akıllıdır.

 

SCADA yazılımları ve OPC sunucularının çalışma prensibi, genelde istemci (client) cihazlar ile sunucular arasında bir sorgulama modeline dayanır. SCADA yazılımı OPC sunucuya sorgulama yollar, sunucu ise PLC/ RTU/IO modülleri anlık sensör değerleri için sorgular. Bunu takiben SCADA operatörü yazılımın kullanıcı ara yüzünde sağlanan bilgilere cevaben gerekli komutları girer. Bazı değerlerin diğerlerine kıyasla daha sık veya nadiren sorgulanması mümkün olsa da, kritik değerleri denetleyen sensörlerin (örneğin kilitli bir kapının açık veya kapalı oluşu), gerekli müdahalenin yapılabilmesi (örneğin güvenlik personeline uyarı gönderilmesi) için saniyede bire kadar sık sorgulanması gerekir. Bu sorgulama sonucunda SCADA sisteminin de uygun biçimde bilgilendirildiğinden emin olunmalıdır. Örneğin, kapının durumu her 5 saniyede bir sorgulanıyorsa ancak kapı 4 saniyelik bir zaman aralığında açılıp kapandıysa, SCADA sistemi kapının açıldığına dair uyarılmayacaktır. Sadece bir kapının durumunun denetlendiği durumlarda sık sorgulama yapmak büyük bir sorun teşkil etmeyecektir. Ancak yüzlerce kapının durumunu denetleyen SCADA sistemleri için bu kadar çok sayıda sensörün yüksek sıklıkta sorgulanması, ağ üzerinde büyük miktarda bant genişliği işgal edebilir. Bunun sonucunda aynı ağa bağlı diğer uygulamaların yavaşlamasına neden olabilir.

On yıl kadar önce Moxa, ioLogik ürünlerinde kullandığı patentli Active OPC konseptini piyasaya sunmuştur. Basitçe özetlemek gerekirse, Active OPC, sıradan I/O cihazlarına OPC sunucusu ile bağlantıya geçmeleri için gerekli akıllı altyapıyı sağlar. Diğer bir deyişle, I/O cihazları çeşitli lokal seri bağlantılarla ioLogik’lere bağlı olduğundan, ioLogik modüller bu cihazlara ethernet ağına yük bindirmeden istediği kadar sıklıkta sorgulama yapabilir. Yalnızca önceden yapılandırılan belirli durumlarda OPC sunucusuna değerleri (ethernet ağı üzerinden) gönderir. Şekil 1’de gösterildiği gibi, alışılagelmiş istemci-sunucu sorgulama modelinin çalışma şekli, OPC sunucusu I/O değerlerini çeşitli cihazlardan bir nevi “çekiyor” olduğundan, zaman zaman “pull” (çekme) olarak adlandırılır. ioLogik modüllerin Active OPC çalışma şekli ise, ioLogik’ler I/O değerlerini çeşitli cihazlardan OPC sunucusuna “itiyor” olduğundan “push” olarak tanımlanır.

Yakın zamanda yaşanan bir gelişmede, 2008 yılında OPC Foundation “OPC Unified Architecture” (OPC UA) haberleşme protokolünde “istisna bazlı raporlama” yöntemini standardize etmiştir. OPC UA, SCADA yazılımı ile OPC sunucusu arasındaki haberleşmenin kontrolünde “abonelik ve denetlenen öğe” (subscription and monitored item) modeli kullanır. OPC UA, operatörlerin doğrudan SCADA sistemleri üzerinden OPC sunucularının çeşitli I/O cihazlarıyla nasıl etkileşim içerisinde olacağını yapılandırmalarını sağlıyor olması açısından son derece yenidir. Hatta istisna bazlı raporlama yöntemi OPC UA sunucusunun değerlerini SCADA yazılımına “itiyor” olduğundan, OPC UA’nin Active OPC ile birlikte kullanımı “push-push stratejisi” de dediğimiz, kayda değer miktarlarda bant genişliğinden tasarruf potansiyeline sahip bir uygulama ortaya koyar. Bu teknik yazıda, sorgulama bazlı ve istisna bazlı veri güncelleme arasındaki farkı açıklamasının yanı sıra, hangi yöntemin çeşitli I/O cihazlarınız için daha uygun olduğuna dair karar vermenizi kolaylaştıracak bazı genel geçer kurallar ortaya koyacak, bu alanda büyük yenilik getiren Moxa’nın yeni MX-AOPC UA sunucu çözümünden de bahsediliyor.

Sorgulama Veya İstisna Bazlı Veri Güncellemesi

Günümüzde uzun süreden beri sorgulama yoluyla veri güncellemesi OPC sunucuları ile OPC istemcileri (örneğin, SCADA yazılımları) arasındaki haberleşmede bir endüstri standardı haline gelmiştir. Ancak artık mühendislerin sorgulama veya istisna bazlı veri güncelleme arasında seçim yapması mümkündür. Genelde hangi seçeneğin kullanılacağı iki unsura bağlıdır: (1) sensör değerlerinin hangi sıklıkta değiştiği ve (2) bir değerin değişimi hakkında ne kadar acil bilgi almak gerektiği. Sıkça değişen sensör değerlerinin zaman içindeki değişimi hakkında doğru bir tablo ortaya konabilmesi için bu değerlerin sık sık örneklendirilmesi gerekir. Çok sık değişim göstermeyen sensör değerleri için ise, örneklendirme çok sık yapıldığında oldukça fazla bant genişliği heba edilebilir. Ancak örneklendirme çok seyrek yapılırsa da kritik veriler tamamıyla gözden kaçabilir (bir kapının açılıp kapanmış olması gibi). Peki, OPC UA sunucusu ile veri güncellemesi tam olarak nasıl işler?

Sorgulama Bazlı Veri Güncellemesi

Her OPC UA sunucusu, alışılagelmiş OPC DA sunucularındakiyle birebir aynı çalışma şekli ve yapılandırma prosedürüyle hala sorgulama bazlı veri güncellemesini destekler.

İstisna Bazlı Veri Güncellemesi

İstisna bazlı raporlamaya göre yapılandırıldığında bir OPC UA sunucusu, bir SCADA istemcisini bir denetlenen öğe setine abone yapan “abonelik ve denetlenen öğe” yöntemini kullanır.

OPC UA sunucusu veri noktalarını düzenli “örnekleme aralıklarında” örneklendirir, öğenin değerlerini bir sıraya koyar ve değerleri düzenli “yayın aralıklarında” yayınlar. Bu işlem hakkında önemli bir özellik de örneklenen değerin bir önceki örneklemeye göre değişmediği durumda değerin yayınlama sırasına sokulmamasıdır. Bu, istisna bazlı raporlama konseptinin de özü olan, değişmeyen değerlerin yayınlanmaması anlamına gelir (Şekil 2). OPC UA’in uzun süreli durgunluk durumlarında aktiflik sinyallerinin gönderilmesini de desteklediği, böylece bağlantının her iki tarafının da birbirinin hala aktif olduğundan emin olmasının sağlandığı, dolayısıyla bağlantının kesilmesinin önlenebileceği de not edilmelidir.

İstisna bazlı güncellemeyi etkinleştirmek için OPC istemcisi üzerinde iki ayarın yapılandırılması gerekir: örnekleme aralığı ve yayın aralığı (Şekil 3). Örnekleme aralığı sunucunun denetlenen cihazdaki değerlerde bir değişim olup olmadığını ne kadar sıklıkla kontrol edeceğini belirlerken, yayın aralığı sunucunun ne kadar sıklıkla istemciye bildirim yapacağını tanımlar. Örnekleme aralığı, yayın aralığından daha kısa olabilir. Bu durumda, bildirimler yayın zamanı gelene kadar sunucuda sıralanır. Yayın zamanı geldiğinde, sunucu sırada bulunan tüm bildirimleri istemciye iletir.

İstisna bazlı veri güncellemede I/O değerleri denetlenen sistem durumu değişmediği takdirde gönderilmediğinden, operatörler ağ üzerinde gerekli bant genişliği miktarını büyük oranda azaltabilir. Bu fayda özellikle değer değişim sıklığının sorgulama aralığından daha düşük olduğu, bir kapının açılıp kapanması gibi durumlar için geçerlidir.

İstisna bazlı raporlama da, hem sunucu hem de istemci bilgisayarlarda zamanaşımı ve yeniden denemeleri ele almada harcanan işlem kaynaklarından tasarruf sağlar.

Değer değişim sıklığı sorgulama aralığından daha yüksek ve aciliyet söz konusu ise, verinin istisna bazlı güncellemesi yine daha doğru bir seçim olacaktır. Öte yandan istisna bazlı raporlama yine de çok miktarda verinin kısa bir sürede aktarımına, dolayısıyla da ağda tıkanıklığa neden olabilir. Bu tıkanıklık, analog veri için uygun bir “ölü bant” atanarak bir derece giderilebilir, veya veri gönderilmeden önce uygun bir nümerik işleme algoritması kullanılarak aktarılacak veri miktarı azaltılabilir. Öte yandan, değer değişim sıklığı sorgulama aralığından yüksek ise ve aciliyet durumu yoksa (bir sıvının sıcaklık denetimi gibi durumlarda), sorgulama bazlı veri güncellemesi sistem için daha uygun olabilir.

Çoğu OPC UA sunucusu, I/O cihazlarından veri toplamak için Modbus gibi sorgu tipi bir protokol kullanır. Ancak, yüzlerce veya binlerce etiketin sorgulanması son derece verimsizdir. Eğer her iki veri güncelleme tipi de mevcut ise, cihaz etiketlerini Şekil 4’te belirtilen dört kategoriye ayırarak her bir kategoride kullanılması en uygun yöntemin ne olduğuna karar verilebilir. Böylece sorgu tipi yöntemler, yüksek frekanslı ama kritik olmayan etiketlerin SCADA sisteminde güncellenmesinde kullanılarak genel sistem verimliliği artırılabilir.

Çoğu OPC sunucusu için etiket isimlerinin Ethernet veya seri gibi bir haberleşme tipi ile başlaması, bunu cihaz isminin, daha sonra da I/O noktası isminin takip etmesi gerekir. Örneğin, bir pompanın açık-kapalı durumu için etiket ismi Ethernet.Cihaz.Pompa_Durumu olabilir. Öte yandan, sensörün yeri ait olduğu etiket isminde bulunmadığından ve tek bir SCADA sistemi binlerce etiket içerebildiğinden, operatörlerin yalnızca etiket ismine bakarak hangi cihazdan bahsedildiğini anlaması neredeyse imkânsızdır. Bu nedenle etiketler genellikle daha detaylı açıklamaların yer aldığı bir Excel dosyasında etiket isimleriyle beraber düzenli biçimde saklanır.

Bu sorunu aşmanın bir yolu, cihazın yerinin de cihaz ismine dâhil edilerek etikette yer almasıdır. Örneğin, bir SCADA sistemi aynı model I/O cihazını PompaA ve PompaB adlı iki pompanın denetlenmesinde kullanıyor ise, etiket isimleri, cihazların ayırt edilebilmesi için Ethernet. Cihaz_SahaA.Pompa_Durumu ve Ethernet.Cihaz_SahaB. Pompa_Durumu şeklinde yazılabilir.

Peki, neden etiket isimleri haberleşme kanalı ile başlamalıdır? Eğer etiket isimleri asıl uygulamanın yapısına dayanıyor ise, kullanıcıların uygun etiket ismi belirlemesi daha kolay olur. İki etiket isimlendirme stratejisi arasındaki fark, Şekil 5’te gösterilmektedir. Soldaki şema daha az sezgisel olup A sahasında da seri cihaz kullanılıyorsa karışıklık yaratabilir. Bu durumda Saha A seri grubun altında da yer alacaktır. Sağ taraftaki şema ise aynı sistemin uygulamanın yapısına göre gruplandığı versiyonu gösterir. Bu durumda A sahasındaki tüm cihazlar Saha A grubu altında yer alacak, ve etiket isimleri SahaA.Cihaz.Pompa_Durumu ve SahaB.Cihaz.Pompa_Durumu şekline yazılabilecektir. Bu etiket isimleri daha kolay okunabilir olup SCADA sisteminizin yapılandırılmasını daha kolay hale getirir.

OPC UA, Sunucu Ve İstemci Cihazların Bağlanmasını Kolaylaştırıyor

OPC’yi sunucu ve istemci arasında farklı bilgisayarlar üzerinden yapılandırmak, OPC UA yokken operatörler için son derece büyük bir dertti. Örneğin, kullanıcının hem sunucu hem de istemci bilgisayarlara tamamen aynı hesap ve şifre ile giriş yapması gerekiyordu. Bu zorunluluk, kullanışlılık açısından bakıldığında son derece gereksiz bir formalite idi. Ayrıca, kullanıcı DCOM güvenliğini yapılandırabilmek için sezgisellikten uzak, detaylı bir talimat serisini adım adım izlemek zorundaydı.

Buna karşılık OPC UA veri alışverişi için optimize edilmiş bir TCP tabanlı UA ikili (binary) protokol kullanır. Bu protokol ile haberleşme, Şekil 6’da da gösterildiği gibi, güvenlik duvarındaki tek bir yapılandırılabilir portun açılmasıyla etkinleştirilebilir.

Kullanıcılar, her hedefin tek bir portu temsil ettiği OPC sunucu hedefleri için birden çok TCP URL oluşturabilir. OPC UA istemcileri, OPC UA sunucusuna bağlanabilmek için yalnızca sunucu hedefine ait URL’ye ihtiyaç duyar.

X509 sertifikaları gibi entegre güvenlik mekanizmaları, internet üzerinde güvenli haberleşmeyi güvence altına alır. Kullanıcılar, OPC UA istemcisi ile sunucu arasında “İmzala ve Şifrele” (Sign and Encrypt) gibi güvenlik politikaları tanımlayabilir (Şekil 7).

Kullanıcıların sunucu ve istemci arasında yetkilendirme yapmak için yalnızca OPC UA istemcisinden “Certificate Authority” (Sertifika Yetkilisi) dosyasını indirmesi ve sunucunun “Certificate Authority” dosyasını ise OPC UA istemcilerine yüklemesi yeterlidir (Şekil 8).

Daha sonra, OPC UA istemcisinin ağ üzerindeki erişilebilir OPC UA sunucularını tespit etmesi için “Discover Servers” (Sunucu Bul) fonksiyonu kullanılabilir (Şekil 9).

Son olarak, kullanıcılar OPC UA sunucusuna bağlanmak için TCP URL’yi seçebilir (Şekil 10).

Moxa’nın MX-AOPC UA Sunucu Çözümü

MX-AOPC-UA Sunucusu, Moxa’nın patentli Active OPC denetleme teknolojisini kullanarak, Modbus protokol desteğini de bünyesinde bulundurarak lokal cihazlar ile uzak SCADA sistemi arasında güvenli ve sağlam bir ağ geçidi görevi görür. Moxa, Active OPC Sunucusunun piyasaya sürülmesiyle sorgulama veya “pull tipi”nin aksine “push tipi” I/O işletiminin otomasyon sektöründe kullanımının öncüsü olmuştur. Patentli MX-AOPC UA sunucusu, hem sorgulama hem de istisna bazlı raporlama yapısını standart bir OPC UA protokolünün yanında sunarak, kullanıcılara Moxa cihazlarıyla pull veya push tipi haberleşme seçimini yapma olanağı verir (Şekil 11).

MX-AOPC UA Server tasarım mantığı, kullanıcı-uygulama temellidir. Şekil 12’de görüldüğü gibi, kullanıcılar uygulamalarına göre “SiteA” ve “SiteB” gibi cihaz grupları oluşturabilir.

Burada gösterilen örnekte, her sahada pompa durumunu denetleme amacıyla aynı ioLogik E1210 modülü kullanılmıştır.

SCADA sisteminizin yapılandırılma zamanı geldiğinde etiket isimleri (Şekil 13) çok daha net ve okunabilir halde olacaktır.

Moxa’nın Geniş Veri Toplama Ürün Seçenekleri

Moxa, sunduğu geniş endüstriyel veri toplama çözümü yelpazesinde güvenilirliği, yazılımın kolay kullanılabilir oluşunu ve genel endüstriyel kullanıma elverişliliği öne çıkarmıştır. Moxa’nın veri toplama çözümleri, her endüstriyel sektörden işletme için büyük faydalar sağlayabilir.

Kaynaklar

Chen, C. Z. K. “How OPC UA Servers Facilitate Efficient SCADA Device Data Management”, Product Manager, Moxa Inc.; OPC Foundation, https://opcfoundation.org/