Modern IIoT'de SCADA ve Unified Namespace (UNS) hangi rolü üstlenir?

SCADA (Supervisory Control and Data Acquisition), onlarca yıldır fabrikada olan biteni görmenin ve işletmeyi yürütmenin merkezinde yer alıyor.

Bugün pek çok ekip, SCADA'nın daha geniş kurumsal veri mimarisindeki yerini yeniden değerlendiriyor.

Bu değişim operatör panellerini ya da proses kontrolünü ortadan kaldırmakla ilgili değil. Asıl soru, SCADA'nın kurumdaki tüm veri akışlarının geçtiği merkez olarak kalıp kalmaması gerektiği.

Bulutla bağlantılı, analitik kullanan ve birçok sistemin entegre olduğu ortamlarda tüm trafiği SCADA merkezli bir yapı üzerinden geçirmek, entegrasyon maliyetini ve değişiklik yönetiminin yükünü artırabilir. Bu yüzden SCADA'nın bu rolü giderek daha sık Unified Namespace (UNS) yaklaşımlarıyla destekleniyor ya da bu yaklaşımlara bırakılıyor.

Sonuçlar iş yüküne, donanıma ve ağ yapısına göre değişir.

SCADA, kurumsal verinin yeniden kullanımında neden darboğaz oldu?

Klasik otomasyon mimarisinde (ISA-95 modeli) SCADA, PLC katmanının hemen üzerinde yer alır. Geçmişte, sahadaki bir makinenin verisine ihtiyaç duyan her üst seviye yazılım (bir MES, bir geçmiş veri deposu ya da bir ERP sistemi) bu veriyi SCADA'dan istemek zorundaydı.

SCADA böylece fabrika verisine erişimin ana aracısı hâline geldi. Bu da birçok üretici için tekrar tekrar karşılaşılan entegrasyon ve maliyet sorunları doğurdu:

Üreticiye bağımlılık ve büyüme kısıtları

Tüm veri SCADA yazılımı üzerinden aktığı için, büyümek çoğu zaman veri noktası sayısına bağlı daha üst bir lisans kademesine geçmeyi gerektirir. Kestirimci bir yapay zekâ modelini beslemek için on yeni titreşim sensörü bağlamak, çoğu zaman bir sonraki lisans kademesine geçmek demektir. Bazı kurulumlarda bu, ciddi yükseltme maliyetleri anlamına gelir.

Veri eşlemenin işletme yükü

Bir ERP'yi SCADA'ya noktadan noktaya bağladığınızda, kırılgan ve özel olarak kodlanmış bir veri hattı kurmuş olursunuz. Bir PLC mühendisi bir veri noktasının adını Pump_Spd_01 yerine PMP01_Speed yaptığında SCADA eşlemesi bozulur, ERP entegrasyonu çöker ve günlük üretim raporu boş gelir.

Bağlamın kaybolması

SCADA, bulut algoritmaları için değil, ekrana bakan operatörler için tasarlandı. Verinin taşıdığı mühendislik bağlamını büyük ölçüde siler. SCADA ekranı için bir değer yalnızca "65 derece"dir. Kurumsal bir yapay zekânın ise bunun "B hattındaki boya fırınının 2. bölgesinden gelen, 9012 numaralı ürün üretilirken ölçülmüş bir Celsius değeri" olduğunu bilmesi gerekir.

Unified Namespace (UNS) veriyi başka bir yoldan dağıtır

Geleneksel SCADA mimarilerinin bir sınırı, verinin tek bir noktadan dağıtılmasından doğan darboğazdır. SCADA veriyi toplar ve dış sistemler için tek dağıtıcı rolünü üstlenir.

Unified Namespace (UNS), pek çok kurulumda SCADA'yı mimarinin merkezinden çıkarabilir. Sistemleri üst üste yığmak yerine UNS, IT/OT ağının tam ortasına yüksek hızlı, olay güdümlü bir veri merkezi (genellikle bir MQTT sunucusu) yerleştirir.

Bu yaklaşımda birçok sistem, SCADA merkezli bir modelin izin verdiğinden çok daha gevşek bir bağla UNS'e bağlanabilir.

• PLC'ler ve Edge Gateway'ler, makinelerin ham durumunu doğrudan UNS'e yayınlar.
• ERP, günlük üretim planını UNS'e yayınlar.
• Yapay zekâ analitiği, titreşim anomalilerini yakalamak için UNS'e abone olur.
• Peki SCADA? Rolü, merkezdeki aracı olmaktan pek çok kullanıcıdan biri olmaya kayar. UNS verisinin abonelerinden yalnızca biridir; tek işi ekranda grafik çizmektir.

UNS, verinin dağıtılma biçimini neden değiştirir?

Daha az entegrasyon zahmeti

Veriyi üretenlerle kullananlar birbirinden ayrıldığında, yeni bir analitik uygulaması eklemek çoğu zaman daha az yeniden çalışma gerektirir. Gereken emek yine de veri sahipliğine ve kurallarına, güvenliğe ve şema disiplinine bağlıdır, ama genellikle noktadan noktaya özel bir bağlantı daha kurmaktan azdır.

Ortak işletme bağlamı

UNS mimarisinde amaç, birçok sistemin yeniden kullanabileceği, anlamı belli tek bir işletme veri akışı yayınlamaktır. Böylece her sistemin kendi eşleme ve adlandırma kurallarını icat etme ihtimali azalır.

Lisans yükünü hafifletmek

Veri açık standartlı bir MQTT Unified Namespace üzerinden aktığı için veri toplamayı SCADA'nın veri noktası sınırlarından bağımsız olarak büyütebilirsiniz. Sahadan kurumsal data lake'inize 50.000 veri noktası aktarmak, illa bir SCADA lisans yükseltmesini tetiklemez.

Unified Namespace'in motoru olarak Proxus

SCADA merkezli bir mimariden uzaklaşmak göz korkutucu gelebilir, ama fiziksel fabrikanızı söküp baştan kurmanızı gerektirmez.

Proxus endüstriyel veri platformu bu geçişi destekler. Edge Gateway'ler onaylanmış kaynaklara bağlanır, verilerini anlamlandırır ve seçilmiş veri sözleşmelerini MQTT tabanlı bir Unified Namespace içine yayınlar; mevcut SCADA ve kontrol sınırları ise olduğu yerde kalır. Proxus Edge Gateway sayısı ve veri hızı üzerinden lisanslanır; veri noktaları, cihazlar, kullanıcılar, panolar ve API çağrıları sayılmaz. Bu yüzden veri ağacına yeni sinyal eklemek lisansı etkilemez. Söz konusu SCADA Ignition ise Proxus ve Ignition karşılaştırması, ikisinin neler yaptığını ve yan yana nasıl çalıştığını anlatıyor.

Modern üretim, insanın sorgulama hızıyla yürüyemez. SCADA ortadan kalkmıyor; operatörlerin hâlâ düğmelere basması ve tankların dolmasını izlemesi gerekiyor. Ama SCADA'nın endüstriyel verinin toplandığı ana katman olduğu dönem sona erdi.

Bu yaklaşım ne zaman uygun olmayabilir?

• Düşük frekanslı telemetri, dağıtık bir mimarinin tüm karmaşıklığına değmeyebilir.
• Tek hatlı küçük tesisler önce daha sade mimarileri tercih edebilir.
• Katı eski sistem kısıtları aşamalı bir geçiş gerektirebilir.
• Emniyet açısından kritik kapalı çevrim kontrol, PLC ve emniyet PLC'si katmanlarında kalmalıdır.

Gözlenen performans iş yükünün niteliğine, düğüm kapasitesine ve kurulum tasarımına bağlıdır.

Sık sorulan sorular

Mevcut SCADA'mı hemen değiştirmeli miyim?

Hayır. SCADA temel görevini yerine getirmeye devam ediyor: operatöre görselleştirme sunmak ve belirli proseslerin elle kontrolünü sağlamak. Azalan şey, SCADA'nın makine verisine giden tek kapı olma rolü. Bir UNS mimarisinde SCADA kapı bekçisi değil, veri ağacına abone olan pek çok kullanıcıdan biridir.

Veri saklama açısından UNS, SCADA'nın geçmiş veri deposuyla nasıl karşılaştırılır?

SCADA'nın geçmiş veri depoları sıkıştırılmış zaman serisi verisini saklar; bu veriye üreticiye özel adlandırmayla, kapalı API'ler üzerinden erişilir. UNS ile beslenen bir data lake ise aynı veriyi anlamıyla birlikte açık formatlarda saklar ve her sistem bu veriye erişebilir. Kritik fark şu: UNS verisi zaten anlamlandırılmıştır (örneğin Plant/Line1/OEE); geçmiş veri deposundaki verinin anlamını çıkarmak için ise elle eşleme gerekir.

Geçiş sırasında SCADA ile UNS'i paralel çalıştırabilir miyim?

Evet, önerilen yaklaşım da budur. UNS'i devreye almanın 3. aşamasında SCADA sistemleri, PLC'leri doğrudan sorgulamak yerine UNS'e abone olacak şekilde adım adım yeniden yapılandırılır. Böylece her şeyi bir anda değiştirmenin riski ortadan kalkar ve her adım ayrı ayrı doğrulanabilir.

Kaynaklar

1. ISA-95 / IEC 62264: Hem SCADA hem de UNS mimarilerinin, farklı yapılarla da olsa dayandığı otomasyon hiyerarşisi standardı.
2. MQTT v5.0 OASIS Standard: SCADA'nın sorgulamaya dayalı veri toplama modelinin yerini alan yayınla-abone ol protokolü. mqtt.org
3. Eclipse Sparkplug: SCADA geçmiş veri depolarının sağladığı anlamsal veri modelini, üreticiye bağımlılık olmadan ekleyen MQTT veri içeriği standardı. sparkplug.eclipse.org