Gerçek Zamanlı İzleme: SCADA’da Alarm Üretimi Nasıl Tasarlanır? (Eşik, Trend ve Anomali Yaklaşımı)
Enerji tesislerinde (özellikle HES’lerde) gerçek zamanlı izleme dendiğinde, çoğu ekip önce “ekranda veri akıyor mu?” sorusunu sorar. Oysa operasyonel değer, verinin akmasından değil; operatörün doğru anda doğru şeyi görmesinden doğar. Bu da alarm tasarımını, yani “hangi koşulda neyi alarm sayacağız ve nasıl sunacağız?” sorusunu merkeze taşır. İyi tasarlanmamış bir alarm sistemi; alarm seli (alarm flood), alarm yorgunluğu ve gereksiz müdahale ile güvenlik ve üretim riskini büyütür. Standartlar da bu nedenle alarm yönetimini “konfigürasyon işi” değil, yaşam döngüsü (lifecycle) olan bir mühendislik disiplini olarak ele alır [1][2].
Bu yazıda SCADA alarm üretimini üç temel yaklaşımla (eşik, trend ve anomali) bütüncül şekilde ele alacağız; HES bağlamında örnek bir senaryo ile kural seti tasarlayacağız; ardından Hydrowise/Renewasoft perspektifinde “sahada çalışır” bir uygulama mimarisine bağlayacağız.
TL;DR
- Alarm tasarımı bir “limit koyma” işi değil; felsefe, rasyonalizasyon, KPI izleme ve değişiklik yönetimi içeren yaşam döngüsüdür [1][2].
- Eşik alarmları hızlıdır ama tek başına yeterli değildir: deadband, gecikme, öncelik ve bağlam yoksa yanlış alarmlar artar [2].
- Trend/derivative alarmları yaklaşan arızayı erken yakalar; operatör için “daha erken, daha sakin müdahale” sağlar.
- Anomali tespiti (istatistiksel/ML) “bilinmeyen bilinmeyenleri” yakalar; ancak model drift, açıklanabilirlik ve yanlış pozitif yönetimi şarttır [3][4].
- Başarılı yaklaşım: alarm KPI’larıyla (alarmlar/saat, sel tanımı vb.) ölç, rasyonalize et, test et, sonra üretime al; HMI/operatör ergonomisini de ISA-101 gibi rehberlerle destekle [5][6].
Kavramlar ve Arka Plan:
Alarm, olay (event) ve bildirim (notification) ayrımı
SCADA ekranında görünen her şey “alarm” değildir. Pratik bir ayrım:
– Event (Olay): Süreçte bir değişiklik kaydı. Operatörün aksiyon alması gerekmeyebilir.
– Alarm: Operatörün tanımlı bir zaman penceresinde aksiyon almasını gerektiren, önceliklendirilmiş ve doğrulanmış uyarı.
– Notification/Bildirim: Bilgi amaçlı hatırlatmalar, bakım çağrıları vb.
IEC 62682 ve ISA-18.2 yaklaşımı, alarmı “operatör eylemi gerektiren” bir unsur olarak ele alır ve yaşam döngüsü boyunca bu niteliğin korunmasını ister [1][2]. Alarmı “her limit aşımı” olarak tanımlamak, alarmı değersizleştirir.
Alarm yaşam döngüsü ve “alarm felsefesi”
ISA-18.2/IEC 62682 çerçevesinde alarm yönetimi; alarm felsefesinin oluşturulması, alarm adaylarının seçimi, rasyonalizasyon, detay tasarım, uygulama, işletim/bakım, performans izleme, değişiklik yönetimi ve denetim adımlarını içerir [2][1]. Buradaki kritik nokta şudur: Alarm yönetimi, bir kez yapılıp bırakılan bir proje değil; yaşayan bir süreçtir.
“Alarm felsefesi” dokümanı; amaçları (güvenlik, çevre, ekipman, üretim), öncelik mantığını, sınıflandırmayı, alarm renk/etiket standartlarını, “kim ne zaman ne yapar” sorumluluklarını, test prosedürlerini ve KPI hedeflerini tanımlar [2].
Alarm seli (alarm flood) ve KPI’lar
Alarm seli; operatörün kapasitesini aşan hızda alarm üretimiyle, doğru müdahalenin gecikmesine yol açan bir durumdur. EEMUA 191 ve sektörel uygulamalar, sel koşullarını ölçülebilir metriklerle tanımlamayı önerir (ör. 10 dakikada 10’dan fazla yeni alarm gibi eşikler) [7]. ISA-18.2’de de performans izleme ve KPI’lar vurgulanır [6].
Bu yazı boyunca kullanacağımız örnek KPI’lar:
– Ortalama alarm hızı (alarmlar/saat)
– En gürültülü ilk 20 alarm (“bad actor alarms”)
– Alarm seli sayısı ve süreleri
– Onay/ack gecikmesi ve operatör iş yükü göstergeleri (proses/insan faktörü çalışmaları, alarm yönetiminin iş yükünü etkilediğini gösterir) [8]
Nasıl Çalışır? Alarm Üretiminin 3 Temel Yaklaşımı
1) Eşik (threshold) tabanlı alarm
En yaygın yöntem, proses değişkeni PV’nin belirli limitleri aşmasıdır: HH/H/L/LL. Ancak pratikte doğru tasarım için şu “mikro-ayarlar” kritiktir:
– Deadband (histerezis): Sınır çevresinde titreşen alarmları azaltır.
– On-delay / Off-delay: Kısa süreli spike’ları filtreler; “gerçek” sorunları ayırır [9].
– Setpoint dinamikliği: Sabit limitler yerine işletme durumuna bağlı limitler (duruma bağlı alarm/state-based) (ör. türbin devreye alma, kapak hareketi, bakım modu).
– Önceliklendirme: Güvenlik/ekipman/üretim etkisi ve zaman kritikliğine göre.
Neden tek başına yetmez? Çünkü eşik, çoğu zaman “sonuç”u yakalar. Bir rulman ısısı HH’e geldiğinde, arıza zaten yaklaşmıştır; trend yaklaşımı daha erken sinyal verir.
2) Trend (rate-of-change / deviation) tabanlı alarm
Trend alarmları, PV’nin değişim hızını (d/dt) ya da referans davranıştan sapmasını alarm koşulu yapar. Örnek:
– “Kapak açıklığı %2 arttığı halde debi artmıyor” (verim kaybı / tıkanma ihtimali)
– “Titreşim RMS 10 dakikada %30 yükseliyor” (yaklaşan mekanik problem)
Trend yaklaşımı iki fayda sağlar:
1) Operatöre daha erken uyarı: müdahale penceresi genişler.
2) Alarm selini azaltma: anlık spike’lar yerine anlamlı değişimi hedefler.
Trend tasarımında dikkat edilmesi gerekenler:
– Örnekleme frekansı ve filtreleme (moving average, median filter)
– Sezonluk/operasyonel rejim değişimleri (gece/gündüz, yük değişimi)
– “Normal trend”in tanımlanması (kıyas için baz çizgi)
3) Anomali (istatistiksel / ML) tabanlı alarm
Anomali tespiti, klasik limitlere sığmayan “alışılmadık” davranışları yakalamayı amaçlar. Chandola vd. (2009) çalışması, anomali tespitini teknik kategoriler ve varsayımlar üzerinden sistematik biçimde sınıflandırır; en kritik mesaj şudur: Her yöntem belirli varsayımlarla çalışır; domain’e göre uygun yöntem seçilmelidir [3][4].
SCADA/ICS bağlamında anomali tespiti; ekipman arızası, sensör hatası, süreç sapması veya siber manipülasyon gibi durumların erken işaretini yakalamada kullanılabilir. Güncel literatürde ICS ölçüm verileri üzerinden derin öğrenme tabanlı anomali yaklaşımlarının performansı değerlendirilmektedir [10]. Ancak üretim ortamında başarı; yalnızca AUC/accuracy değil, aşağıdaki operasyonel şartlara bağlıdır:
– Yanlış pozitif maliyeti: Operatör güveni kaybolursa sistem devre dışı kalır.
– Drift ve yeniden eğitim: Süreç/ekipman değiştikçe model kayar (concept drift).
– Açıklanabilirlik: “Neden alarm verdin?” sorusuna makul yanıt.
– Güvenlik entegrasyonu: OT güvenliği için izleme ve kayıt süreçleri (NIST OT güvenliği rehberi) [11].
HES/Enerji Tesisi Tarafında Etkisi: Neden Alarm Tasarımı İş Değeridir?
Operatör performansı ve risk
Alarm seli, operatörün bilişsel yükünü artırır; kritik alarmı kaçırma riskini yükseltir. Alarm yönetimi ve otomasyonun operatör iş yükü ve performansı üzerinde etkisini inceleyen insan-döngü çalışmaları bu ilişkiyi vurgular [8]. Ayrıca HMI tasarımının kullanılabilirlik ve performans odağıyla ele alınması gerektiği ISA-101 ailesinde de öne çıkar [5].
Üretim kaybı, ekipman sağlığı ve güvenlik
HES’te alarm tasarımı; doğrudan şu sonuçlarla ilişkilidir:
– Planlanmamış duruş ve üretim kaybı (türbin, jeneratör, trafo, kapak/ızgara sorunları)
– Su yönetimi kararları (debi, rezervuar seviyesi, kapak pozisyonu)
– Çevresel uyum (minimum can suyu, taşkın kontrolü)
– Siber dayanıklılık (beklenmedik komut/ölçüm sapmaları)
NIST’in OT/ICS güvenliği rehberleri, izleme-kayıt ve güvenlik kontrollerinin OT’nin güvenilirlik ve emniyet gereksinimleriyle birlikte ele alınması gerektiğini vurgular [11]. Alarm sistemi; sadece proses değil, güvenlik perspektifi için de kritik bir “erken uyarı” katmanıdır.
Örnek Senaryo: HES’te Alarm Kural Seti Tasarımı (Mini Akış)
Aşağıdaki senaryoda amaç: alarm sayısını artırmadan erken uyarı üretmek ve “operatör aksiyonu”nu netleştirmek.
Senaryo
Bir HES’te türbin ünitesinde şu telemetri toplanıyor:
– Aktif güç (kW/MW)
– Debi (m³/s)
– Kapak/kanat açıları (%)
– Jeneratör yatak sıcaklığı (°C)
– Titreşim (RMS mm/s)
– Yağ basıncı (bar)
– Şebeke frekansı (Hz)
Hedef
1) “Anlık eşik” alarmlarını minimumda tutmak
2) Trend ile erken uyarı
3) Anomali ile karmaşık sapmaları yakalamak
4) Alarm selinde otomatik bastırma/özetleme (suppression/shelving) kuralları
Adım adım tasarım (ISA-18.2 / IEC 62682 uyumlu yaklaşım)
Adım 1 — Alarm felsefesi ve sınıflar
– Kritik (Safety/Trip), Yüksek (Equipment protection), Orta (Operational), Düşük (Advisory) sınıfları; renk/etiket standardı; ack zorunluluğu [2][1].
Adım 2 — Alarm rasyonalizasyonu (Master Alarm Database)
Her alarm için şu alanları doldurun: tag, koşul, amaç, olası nedenler, operatör eylemi, beklenen süre, öncelik, deadband/delay, bastırma koşulları [2][9].
Adım 3 — Üç katmanlı alarm üretimi
(A) Eşik alarmları
– Titreşim HH: RMS > X mm/s ve on-delay 30 s (kısa spike’ları ele)
– Yatak sıcaklığı HH: T > Y °C ve off-delay 60 s (histerezis)
– Yağ basıncı LL: P < Z bar (kritik; hızlı)
(B) Trend alarmları (erken uyarı)
– Titreşim artış hızı: d(RMS)/dt > a eşiği (10 dk pencerede)
– Sıcaklık trendi: 20 dk’da +ΔT (işletme durumuna göre dinamik eşik)
– Verim sapması: (MW / debi) oranı 15 dk’da %k düşüş → “ızgara tıkanma/kapak sorunu” olasılığı
(C) Anomali alarmları (bağlamsal)
– Çoklu değişken anomali skoru: [MW, debi, kapak, titreşim, sıcaklık, yağ basıncı] vektöründen öğrenilen normal davranıştan sapma.
– Eşik: skor > s ve 5 dk kalıcılık → “Anomali Uyarısı (Advisory)”
– Açıklama: en çok katkı veren 3 değişken (ör. titreşim + sıcaklık + verim)
Adım 4 — Alarm seli yönetimi
– Sel tanımı: 10 dakikada >10 yeni alarm → “Alarm seli modu” [7]
– Sel modunda: düşük öncelikli advisory alarmları özetle; kritik alarmları öne çıkar.
– “Bad actor” alarmlar için otomatik inceleme listesi (haftalık rapor)
Adım 5 — KPI ve sürekli iyileştirme
– Günlük/haftalık alarm raporu: alarmlar/saat, ilk 20 gürültülü alarm, sel olayları, ack gecikmeleri [6][7].
– Değişiklik yönetimi: alarm limitleri ve bastırma kuralları “MOC” süreciyle güncellenir [2].
Teknik Not: Alarm Yaşam Döngüsü (ISA-18.2 / IEC 62682)
- Alarm Felsefesi → standartlar, hedef KPI, roller
- Tanımlama → alarm aday havuzu
- Rasyonalizasyon → gereksiz alarmları ele, öncelik/aksiyon yaz
- Uygulama → HMI + mantık + test
- İzleme & Değerlendirme → KPI, bad actor, sel analizi
- Değişiklik Yönetimi & Denetim → sürekli iyileştirme
(Kaynak: [1][2][6])
Risk Kutusu: SCADA Alarm Tasarımında En Sık Hatalar
- Her event’i alarm yapmak (alarm şişmesi)
- Deadband/delay olmadan limit koymak (titreşimli sahte alarmlar)
- Operatör eylemi yazmamak (“ne yapayım?” belirsizliği)
- Alarm önceliklerini rastgele dağıtmak
- KPI izlememek (sistem zamanla bozulur)
- HMI tasarımını ihmal etmek (ISA-101 ilkeleriyle uyumsuz ekranlar) [5]
- Anomali modelini “tek seferlik” kurmak (drift ve güven kaybı) [3][11]
Alarm Selini Azaltmanın 7 Kuralı
1) Alarm ≠ Event: Aksiyon gerektirmiyorsa alarm değildir.
2) Deadband + delay olmadan limit koyma.
3) Duruma bağlı alarm (startup/maintenance) tasarla.
4) Trend alarmlarıyla erken uyarı ekle.
5) Anomaliyi “advisory + açıklama” olarak konumlandır.
6) KPI’larla izle: alarmlar/saat, bad actor, sel.
7) MOC (değişiklik yönetimi) ile sürdürülebilir kıl.
(Kaynak dayanağı: [1][2][6][7][11])
Hydrowise / Renewasoft Yaklaşımı: “Sahada Çalışır” Alarm Tasarımı
Bu noktada asıl soru şudur: “Bu prensipleri hayata geçirirken, veri akışı ve operasyonel süreç nasıl yönetilecek?” Hydrowise/Renewasoft perspektifinde etkili bir alarm yönetimi mimarisi üç katmanda ele alınabilir:
1) Veri katmanı: Güvenli ve sürdürülebilir telemetri
– SCADA’dan zaman serisi veri toplama (MW, debi, kapak, titreşim, sıcaklık vb.)
– Zaman damgası senkronizasyonu (NTP/PTP) ve veri kalitesi kontrolleri
– OT güvenliği gereksinimleri (segmentasyon, kayıt/izleme, yetkilendirme) ile uyum [11]
2) Analitik katman: Kural + istatistik + ML hibriti
– Kural motoru: eşik ve trend alarmları (konfigüre edilebilir)
– Anomali servisi: çok değişkenli skor üretimi; drift izleme; açıklama üretimi (feature contribution)
– Alarm korelasyonu: aynı kök nedenden gelen alarm kümeleri (operatör yükünü azaltır)
3) Operasyon katmanı: Alarm felsefesi, KPI ve değişiklik yönetimi
– “Master Alarm Database” yaklaşımıyla rasyonalizasyon çıktılarının tek merkezde yönetimi [2][9]
– KPI paneli: alarmlar/saat, sel olayları, bad actor listesi [6][7]
– MOC süreci: limit güncelleme, bastırma kuralı değişimi, versiyon takibi [2]
İç link önerileri (site içi):
– /hydrowise/scada-entegrasyonu
– /hydrowise/gercek-zamanli-izleme
– /hydrowise/predictive-maintenance
– /renewasoft/ot-guvenligi
Dış link (otorite kaynak):
– NIST OT güvenliği rehberi (SP 800-82r3) [11]
– IEC 62682 alarm yönetimi standardı sayfası [1]
Sık Sorulan Sorular (FAQ)
1) Kaç alarm “fazla” sayılır?
Tek bir sayı her tesise uymaz; ancak ISA-18.2 ve endüstri pratikleri KPI’larla (alarmlar/saat, sel tanımı) yönetimi önerir [6][7].
2) Eşik alarmları mı, anomali mi daha iyi?
İkisi rakip değil tamamlayıcıdır. Eşik “güvenlik/koruma”, trend “erken uyarı”, anomali “karmaşık sapma” için uygundur [2][3].
3) Yanlış pozitifleri nasıl azaltırım?
Deadband/delay, duruma bağlı bastırma, trend penceresi optimizasyonu ve anomali skorunun kalıcılık şartı gibi yöntemler birlikte kullanılmalıdır [2][9].
4) Alarm seli olduğunda ne yapmalı?
Önce tanım ve ölçüm (10 dk’da >10 alarm gibi), ardından düşük öncelikleri özetleme/bastırma ve bad actor iyileştirmesi gerekir [7][6].
5) Alarm rasyonalizasyonu pratikte nasıl yapılır?
Bir atölye çalışmasıyla (operatör + bakım + proses + otomasyon) her alarmın “amaç–neden–aksiyon” üçlüsü yazılır; sonuç Master Alarm Database olur [2][9].
6) Anomali modeli ne sıklıkla güncellenmeli?
Süreç değişimine bağlıdır; drift izleme ve periyodik yeniden eğitim planı gerekir [3][11].
7) HMI tasarımı alarm performansını etkiler mi?
Evet. ISA-101, kullanılabilirlik ve performans odaklı HMI yaklaşımı önerir; alarmın görünürlüğü ve operatör yüküyle doğrudan ilişkilidir [5].
Sonuç
SCADA alarm üretimi; limit koymaktan çok daha fazlasıdır: yaşam döngüsü yaklaşımıyla (felsefe → rasyonalizasyon → KPI → MOC) yönetilmezse, alarmlar zamanla gürültüye dönüşür. HES’lerde bu gürültü; üretim kaybı, ekipman hasarı ve güvenlik riskini büyütür. En etkili sonuç, eşik + trend + anomali yaklaşımlarının operatör ergonomisi ve performans KPI’ları ile birlikte tasarlanmasıyla alınır [1][2][5][6].
Uygulanabilir bir sonraki adım:
1) Mevcut alarm envanterinizi çıkarın (1 haftalık KPI raporu).
2) İlk 20 bad actor alarmı seçin ve rasyonalizasyon atölyesi yapın.
3) 1 kritik ekipman için (ör. türbin rulman) trend alarmı ekleyin.
4) Anomaliyi “advisory + açıklama” olarak pilot başlatın.
5) Hydrowise ile KPI paneli + MOC sürecini devreye alın.
Kaynakça
[1] International Electrotechnical Commission (IEC). IEC 62682:2014 — Management of alarm systems for the process industries. 2014. (https://webstore.iec.ch/en/publication/7363) Erişim: 2026-02-22
[2] International Society of Automation (ISA). Understanding and Applying the ANSI/ISA 18.2 Alarm Management Standard (PAS). (PDF). (https://www.isa.org/getmedia/55b4210e-6cb2-4de4-89f8-2b5b6b46d954/PAS-Understanding-ISA-18-2.pdf) Erişim: 2026-02-22
[3] Chandola, V., Banerjee, A., & Kumar, V. Anomaly Detection: A Survey. ACM Computing Surveys, 41(3). 2009. (https://dl.acm.org/doi/10.1145/1541880.1541882) Erişim: 2026-02-22
[4] Chandola, V. et al. Anomaly Detection: A Survey (technical report PDF). 2009. (https://cucis.ece.northwestern.edu/projects/DMS/publications/AnomalyDetection.pdf) Erişim: 2026-02-22
[5] International Society of Automation (ISA). ISA-101 Series of Standards (HMI usability and performance). (https://www.isa.org/standards-and-publications/isa-standards/isa-101-standards) Erişim: 2026-02-22
[6] Yokogawa. Implementing Alarm Management per the ANSI/ISA-18.2 Standard (Control Engineering). (https://www.yokogawa.com/tr/library/resources/media-publications/implementing-alarm-management-per-the-ansi-isa-182-standard-control-engineering/) Erişim: 2026-02-22
[7] Emerson. Alarm Management By the Numbers (EEMUA-191 metrics). (PDF). (https://www.emerson.com/documents/automation/article-alarm-management-by-numbers-deltav-en-38292.pdf) Erişim: 2026-02-22
[8] Besuijen, R. et al. Impact of alarm management and automation on abnormal operations: A human-in-the-loop simulation study. 2023. Erişim: 2026-02-22
[9] Emerson. Alarm Rationalization — White Paper. (PDF). (https://www.emerson.com/documents/automation/white-paper-alarm-rationalization-deltav-en-56654.pdf) Erişim: 2026-02-22
[10] Zhao, X. et al. Anomaly Detection Approach in Industrial Control Systems Based on Measurement Data. Information, 13(10), 450. 2022. (https://www.mdpi.com/2078-2489/13/10/450) Erişim: 2026-02-22
[11] Stouffer, K. et al. NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security. 2023. (https://csrc.nist.gov/pubs/sp/800/82/r3/final) Erişim: 2026-02-22