SCADA Mimarisi Neden Evrilir?

Bir SCADA sistemi büyüdükçe yalnızca tag sayısı artmaz; aynı zamanda veri toplama sıklığı, alarm üretim hızı, geçmiş veri sorguları, kullanıcı etkileşimleri ve dış sistemlerle yapılan veri alışverişi de artar. Bu işlemlerin aynı süreç üzerinde yoğunlaşması, bir bileşenin performansındaki değişimin diğer fonksiyonları doğrudan etkilemesine neden olabilir.

Temel mimari yaklaşım: Gerçek zamanlı kontrol ve operatör etkileşimi kritik olduğu için, yüksek kaynak tüketen arşivleme, geçmiş veri görselleştirme, alarm analizi ve raporlama gibi işlemlerin zaman içinde ayrı bileşenlere taşınması; sistemin daha kararlı, ölçeklenebilir ve yönetilebilir hale gelmesini sağlar.

Bu nedenle mimari evrim, yalnızca yeni yazılımlar eklemek anlamına gelmez. Asıl gelişim, her yazılım bileşeninin belirli bir göreve odaklanması ve bileşenler arasındaki iş yükünün dengeli biçimde dağıtılmasıdır.

1. Birinci Nesil Mimari – 2023 Sürümü

Birinci nesil yapıda SCADA sisteminin temel işlevleri tek bir yazılım bileşeni olan SCADA RUNTIME üzerinde toplanmıştır. Bu yaklaşım başlangıç ve orta ölçekli uygulamalarda yalın bir işletim modeli sunarken, sistem büyüdükçe farklı iş yüklerinin aynı süreç üzerinde rekabet etmesine neden olabilmektedir.

SCADA RUNTIME tarafından üstlenilen başlıca görevler:

  • Cihazlardan proses verilerinin okunması ve veri toplama.
  • Okunan verilerin operatör ekranlarında gerçek zamanlı gösterilmesi.
  • Tesis kontrol ve kumanda işlemlerinin yürütülmesi.
  • Proses verilerinin arşivlenmesi.
  • Alarm üretilmesi, alarm yönetimi ve alarm gösterimi.
  • MODBUS, OPC ve benzeri arayüzlerle verilerin diğer sistemlere sunulması.
  • Geçmiş verilerin görselleştirilmesi.
  • Geçmiş alarmların listelenmesi ve incelenmesi.

1.1. Monolitik Yapının Performans Sınırları

Tüm görevlerin tek yazılım süreci altında yürütülmesi; özellikle çok sayıda tag içeren, yüksek veri frekansına sahip veya yoğun geçmiş veri sorgulaması yapılan projelerde CPU, bellek ve disk I/O kaynaklarının aynı anda zorlanmasına yol açabilir.

  • Binlerce veriye ilişkin geçmiş arşiv sorguları sırasında operatör ekranlarında yavaşlama.
  • Arşivleme işlemlerinin gerçek zamanlı görselleştirme performansını etkilemesi.
  • Yoğun alarm trafiğinin kontrol ve kullanıcı arayüzü işlemleriyle aynı kaynakları kullanması.
  • Tek bir bileşendeki kaynak tüketiminin diğer SCADA fonksiyonlarına doğrudan yansıması.

Mimari sınırlama: Monolitik yapıdaki temel sorun, tek başına herhangi bir fonksiyonun yetersiz olması değil; birbirinden farklı karakterdeki gerçek zamanlı, arşivleme, alarm ve analiz iş yüklerinin aynı çalışma ortamında toplanmasıdır.

2. İkinci Nesil Mimari – SCADA RUNTIME + EVENT RECORDER

Birinci nesil yapıda ortaya çıkan performans darboğazlarını azaltmak amacıyla ikinci nesilde yük ayrıştırma yaklaşımı benimsenmiştir. Bu aşamada veri toplama ve arşivleme görevleri SCADA RUNTIME'dan ayrılarak EVENT RECORDER bileşenine aktarılmıştır.

Bileşen Temel Görevler Mimari Rol
SCADA RUNTIME Gerçek zamanlı veri görselleştirme, operatör arayüzleri ve tesis kontrol işlemleri. Operasyon ve kontrol katmanı.
EVENT RECORDER Veri toplama, arşivleme, alarm türetme, alarm arşivleme ve MODBUS/OPC gibi arayüzlerle veri sunumu. Veri toplama ve kayıt katmanı.

Bu görev ayrımı sonucunda SCADA RUNTIME üzerindeki CPU ve I/O yükünün azaltılması, operatör ekranlarının daha akıcı çalışması ve veri toplama ile arşivleme süreçlerinin daha kararlı yürütülmesi hedeflenmiştir.

2.1. Yedekli Çalışma Yeteneği

İkinci nesil mimarinin önemli kazanımlarından biri de uygun yapılandırmayla yedekli çalışma senaryolarının oluşturulabilmesidir. Bir EVENT RECORDER cihazlardan veri okuyarak aynı veriyi hem SCADA RUNTIME'a hem de yedek EVENT RECORDER'a iletebilir. Böylece veri toplama ve kayıt katmanında süreklilik desteklenebilir.

Yedeklilik yaklaşımının amacı: Tek bir kayıt bileşeninin devre dışı kalması durumunda veri toplama ve sistem sürekliliği açısından alternatif bir çalışma yolunun hazır tutulmasıdır.

3. Üçüncü Nesil Mimari – Görevlerin İleri Düzey Ayrıştırılması

İkinci nesil mimaride veri toplama ve arşivleme yükü EVENT RECORDER üzerinden ayrılmış olsa da zaman içinde geçmiş verilerin yoğun biçimde görselleştirilmesi, alarm analizleri ve raporlama gibi işlemler bu bileşenin kaynaklarını yeniden zorlayabilecek hale gelmiştir.

Üçüncü nesil mimarinin temel yaklaşımı, görev ayrıştırmasını bir adım daha ileri taşımaktır. Bu amaçla LIVE EVENTS ve LIVE DASH gibi yeni yazılım bileşenleri devreye alınarak geçmiş veri erişimi, olay inceleme ve web tabanlı analitik işlemlerinin veri toplama katmanından ayrılması sağlanmıştır.

Üçüncü nesil mimarinin temel bileşenleri:

  • SCADA RUNTIME: Gerçek zamanlı veri görselleştirme ve operatör kontrolü.
  • FAST EVENT RECORDER: Veri toplama, arşivleme, alarm türetme, alarm arşivleme ve dış sistemlere veri sunumu.
  • LIVE EVENTS: Geçmiş verilerin görselleştirilmesi ve geçmiş alarmların listelenmesi.
  • LIVE DASH: Web tabanlı veri analitiği, trend analizi, raporlama ve performans değerlendirmeleri.

3.1. Görev Dağılımı ve İş Yükü

Katman Görev Öncelik
SCADA RUNTIME Gerçek zamanlı izleme, operatör ekranları ve tesis kontrolü. Düşük gecikme ve sürekli erişilebilirlik.
FAST EVENT RECORDER Veri toplama, arşivleme, alarm üretimi ve veri sunumu. Yüksek veri sürekliliği ve kayıt güvenilirliği.
LIVE EVENTS Geçmiş veri ve alarm inceleme. Operasyonel inceleme ve olay analizi.
LIVE DASH Web tabanlı analitik, trend, raporlama ve performans değerlendirmesi. Analitik erişim ve karar desteği.

4. Üçüncü Nesil Mimarinin Kazanımları

Üçüncü nesil mimaride amaç yalnızca mevcut performans problemlerini çözmek değildir. Aynı zamanda sistemin gelecekte büyüyebilecek tag sayısı, veri hacmi, kullanıcı sayısı ve entegrasyon gereksinimlerine daha kolay uyum sağlayabilmesidir.

  • Gerçek zamanlı performansın korunması: Operatör ekranları ve kontrol işlemleri, geçmiş veri ve analitik yüklerinden daha fazla ayrıştırılmış olur.
  • Kaynak kullanımının dağıtılması: CPU, bellek ve disk I/O gereksinimleri farklı yazılım bileşenleri ve gerektiğinde farklı bilgisayarlar üzerinde çalıştırılabilir.
  • Ölçeklenebilirlik: Sistemin büyümesiyle birlikte tüm yapıyı değiştirmek yerine ihtiyaç duyulan bileşen ölçeklendirilebilir veya optimize edilebilir.
  • Operasyonel farkındalık: LIVE EVENTS ve LIVE DASH sayesinde geçmiş olaylar, trendler ve performans göstergeleri operasyonel değerlendirmeye daha uygun hale gelir.
  • Bağımsız optimizasyon: Veri toplama, gerçek zamanlı görüntüleme ve analitik fonksiyonları kendi iş yüklerine göre ayrı ayrı optimize edilebilir.
  • Sistem sürekliliği: Yedekli veri toplama ve kayıt senaryolarının desteklenmesiyle mimarinin dayanıklılığı artırılabilir.

5. Üç Neslin Karşılaştırılması

Özellik 1. Nesil 2. Nesil 3. Nesil
Temel yaklaşım Monolitik İlk görev ayrıştırması Dağıtık ve görev ayrıştırılmış
Veri toplama SCADA RUNTIME EVENT RECORDER FAST EVENT RECORDER
Gerçek zamanlı görüntüleme SCADA RUNTIME SCADA RUNTIME SCADA RUNTIME
Geçmiş veri görüntüleme SCADA RUNTIME EVENT RECORDER yükü içinde LIVE EVENTS
Analitik ve raporlama Aynı çalışma ortamında EVENT RECORDER ile birlikte LIVE DASH
Yedeklilik Sınırlı EVENT RECORDER ile desteklenebilir Daha ileri dağıtık yapı yaklaşımı
Ölçeklenebilirlik Sınırlı Artırılmış Yüksek

6. Kurumsal Gelişim ve Mühendislik Perspektifi

Bu mimari değişim, tek seferde gerçekleştirilen bir teknoloji dönüşümünden ziyade gerçek projelerden elde edilen deneyimlerin mimariye yansıtıldığı aşamalı bir mühendislik süreci olarak değerlendirilmelidir.

Kurumsal yazılım geliştirme projelerinde gereksinimler zaman içinde netleşir, performans darboğazları gerçek kullanım koşullarında görünür hale gelir ve çözüm mimarileri sahadaki deneyimle olgunlaşır. Bu nedenle birinci nesilden üçüncü nesile geçiş; önceki yapının tamamen başarısız olduğu anlamına gelmez. Her nesil, kendisinden önceki mimarinin ortaya çıkardığı ihtiyaçlara verilen teknik bir yanıtı temsil eder.

Evrimin temel mantığı: Önce tüm fonksiyonların tek bir yapıda birleştirilmesi, ardından veri toplama ve arşivleme yükünün ayrıştırılması, son olarak geçmiş veri erişimi ve analitik işlemlerin de bağımsız bileşenlere taşınması. Böylece mimari, sistemin gerçek kullanım deneyimiyle birlikte olgunlaşmıştır.

7. Modern Tesisler İçin Üçüncü Nesil Yaklaşım

Yüksek veri hacmine sahip modern enerji tesislerinde SCADA sistemi artık yalnızca operatör ekranlarına veri getiren bir uygulama değildir. Sistem; gerçek zamanlı kontrol, yüksek hızlı veri toplama, uzun dönemli arşivleme, alarm yönetimi, geçmiş olay analizi, web tabanlı izleme ve performans değerlendirmesi gibi birbirinden farklı ihtiyaçları aynı anda karşılamak zorundadır.

Bu nedenle üçüncü nesil mimarinin en önemli özelliği, bu fonksiyonların tek bir süreçte birbirleriyle yarışması yerine uzmanlaşmış yazılım katmanlarına ayrılmasıdır. Böylece gerçek zamanlı operasyon ile geçmişe dönük analiz aynı sistem içerisinde birbirini olumsuz etkilemeden sürdürülebilir.

Örnek iş akışı:

  1. FAST EVENT RECORDER sahadan verileri toplar ve arşivler.
  2. SCADA RUNTIME bu verileri gerçek zamanlı operatör izleme ve kontrolünde kullanır.
  3. LIVE EVENTS geçmiş veriler ve alarmlar üzerinde operasyonel inceleme sağlar.
  4. LIVE DASH verileri web tabanlı analitik, trend ve performans değerlendirmesine dönüştürür.

8. Sonuç ve Değerlendirme

EOS SCADA mimarisinin birinci nesil monolitik yapıdan üçüncü nesil dağıtık ve görev ayrıştırılmış yapıya geçişi; artan veri hacmi, performans beklentileri, süreklilik gereksinimleri ve analitik ihtiyaçların doğal sonucudur.

Birinci nesilde tüm görevler SCADA RUNTIME üzerinde toplanırken, ikinci nesilde veri toplama ve arşivleme EVENT RECORDER'a ayrılmış; üçüncü nesilde ise FAST EVENT RECORDER, LIVE EVENTS ve LIVE DASH ile görev ayrıştırması daha ileri seviyeye taşınmıştır.

Sonuç olarak üçüncü nesil yaklaşım; gerçek zamanlı SCADA performansını koruyan, yüksek veri hacmini yönetebilen, geçmiş veriye erişimi kolaylaştıran, analitik kapasiteyi genişleten ve bileşenlerin bağımsız biçimde optimize edilmesine olanak veren sürdürülebilir bir mimari yaklaşım sunmaktadır.

Önemli değerlendirme: Üçüncü nesil mimarinin sağladığı kazanımların tam olarak elde edilebilmesi için yalnızca yazılım bileşenlerinin kurulması yeterli değildir. Veri akışları, ağ yapısı, arşivleme politikaları, yedeklilik senaryoları, sunucu kaynakları ve işletme prosedürleri birlikte tasarlanmalıdır.

← Önceki İçeriğe Dön