Endüstriyel Otomasyon için Kural Motoru Tasarımı

Endüstriyel dijitalleşme ve otomasyon projeleri genellikle masum görünen, basit bir taleple başlar:

Kural motoru tasarımı deneyimlerime göre, benzer bir paternle tekrar tekrar karşılaştım.

"Eğer pompa tank seviyesi X eşiğini geçerse bana SMS veya e-posta at."

Ancak gerçek bir sahada gereksinimler, genellikle basit eşik kontrolleri (Threshold check) olarak kalmaz. Otomasyon mühendisleri sistemi oturttuktan sonra çok kısa sürede sizden şunları talep etmeye başlar:

• Çok adımlı iş akışları: (EĞER X ise Y'yi tetikle, ardında Z veritabanına log düş)
• Zaman bazlı senkronizasyon: (EĞER Valf-A 5 dakikadan uzun süredir kapalıysa...)
• Farklı hatlardaki verilerin kesişimi: (EĞER Hat 1'in OEE'si %60 altındaysa VE Hat 2 çalışmaya devam ediyorsa...)
• ERP, CMMS entegrasyonu doğuran aksiyonlar: (...O zaman gidip SAP PM modülünde bakım emri aç)

Piyasadaki raf ürünü IIoT akıllı kural motorları genellikle bu kırılma anında yetersiz kalır. Ya basittir (sadece görsel "Eğer A > 10 ise Mail At" bloklarıyla sınırlı kalır ve mimari tıkanır) ya da aşırı karmaşıktır.

Proxus bu probleme farklı ve daha stabil bir mühendislik penceresinden bakar: Vakaların büyük kısmı için esnek Görsel Kural Senaryoları (No-Code) sunarken, geriye kalan kompleks senaryolar için saf C# Script (Kod blokları) desteği verir. Tüm bu mimari altyapı, tek bir sunucuda yüksek hacimli senaryoları düşük gecikmeyle çalıştıran Tekil Aktör (Actor-Based) Yürütme Motoru üzerinde koşar.

Bu davranış, topoloji ve yük özelliklerine göre değişebilir.

Geleneksel Sistemler Neden Otoyolda Kalır?

Proxus'un önerdiği hibrit kural modellemesine dalmadan önce, bir fabrikadaki kural tetiklemelerinin neden klasik sistemleri kilitlediğini anlamalıyız:

Tesisler için kurulan basit bir tetikleme, zamanla kontrolden çıkan önemli bir durum makinesi algoritmasına dönüşür. "Sıcaklık 80°C'yi geçerse mail at" kuralı, kısa sürede "Sıcaklık 80°C'yi 2 dakika boyunca geçerse uyar, AMA fırın Soğutma Modundaysa es geç, AMA sıcaklık 85°C'ye vurursa uyarının şiddetini acil duruma çek" durumuna evrilir. Sürükle ve bırak sistemler bu tarz durumlarda iç içe geçmiş dev bir düğüme döner.

2: Çapraz Cihaz Korelasyonu

Veri korelasyonu zor bir mühendislik problemidir. "Robot-A çalışıyorken (RUNNING) VE Sensör-B debi seviyesi bariz düşüş gösteriyorken VE sistem şu an bakım penceresinde (Maintenance Window) DEĞİLSE alarm çal." Tüm bu sinyalleri farklı asenkron zaman dilimlerinde yakalamak, verileri tek noktada tutmak ve korelasyonunu yapıp aksiyon almak sağlam bir mimari gerektirir.

3: Büyük Ölçekte Performans Çöküşü (Scale)

5.000 sensörü olan ve arkada 2.000 alarm/kural tanımlanmış bir tesiste, sunucu saniyede çok yüksek sayıda şart değerlendirmesi yapmak zorunda kalabilir. Eski tip sistemlerde her tetiklenmede SQL sorgusuna gitmek, iş yüküne ve altyapıya bağlı olarak kısa sürede I/O darboğazı, kuyruk birikimi ve gecikme artışı üretebilir.

Proxus Yaklaşımı: Görsel Motor ve Yazılımın Mükemmel Birleşimi

Görsel Kriter Oluşturucu (Visual Criteria Builder)

Yazılım altyapısı veya geliştirici (Developer) tecrübesi olmayan otomasyon teknisyenleri ve vardiya amirleri için tasarlanmış, sezgisel bir koşul oluşturma arayüzüdür.

Mimari Bileşenler

Tetikleyiciler (Triggers: Neye göre evalüe edeceğim?)

• Veri Alındığında (Data Received): Her yeni telemetri paketi geldiğinde kural anında işletilir.
• Zamanlanmış Görevler (Schedule): Zamana dayalı kalıplar (Örn: Her gün 08:00'da veya her 15 dakikada bir kontrol et).
• Manuel Tetikleme: Operatörlerin test için kuralı arayüz üzerinden anlık çalıştırması.

Kriter İfadeleri (Criteria Expressions: Neyi kontrol edeceğim?) Kurallar, kod yazmaya gerek kalmadan görsel bir ağaç yapısı kullanılarak mantıksal koşulların zincirlenmesiyle oluşturulur:

• Özellik Kontrolleri: [Payload][Key = 'Temperature']
• Sayısal Eşikler: NumericValue > 80
• Bileşik Mantık: Koşulları AND / OR bloklarıyla birbirine bağlama
• Bağlamsal Filtreler: [Attributes][Key = 'Location' AND Value = 'Sector_A']

Aksiyonlar (Actions: Durum sağlandıysa ne yapacağım?)

• Bildirimler: E-posta, SMS, Slack, Microsoft Teams, Discord üzerinden uyarı gönderimi.
• Uç Cihazlara Geri Yazma (Write-Back): Pompayı durdurmak veya valf kapatmak için geri dönüş sinyali atar.
• MQTT Yayınlama: Diğer sistemlerin tüketmesi için Birleşik İsim Alanına (UNS) mesaj iletir.
• REST API ve Webhook: Dış sistemlerin API uçlarını POST isteği ile tetikler.
• CMMS Entegrasyonları: SAP, IBM Maximo gibi sistemlerde otomatik "İş Emri" (Bakım Senaryosu) açar.

Örnek Kural Hiyerarşisi

Karmaşık bir düğüm (node) ağı yerine, mantık temiz bir koşul ağacında yapılandırılır:

-- Veri Geldiğinde Anında Değerlendirilir
[Payload][Key = 'Line1.Robot.Temperature' AND NumericValue > 85]
AND [Attributes][Key = 'Robot.Running' AND Value = 'True']
AND NOT [Attributes][Key = 'MaintenanceMode' AND Value = 'True']
-- Throttle Period (Kısma Süresi) alarm yığılmasını engeller

Sonuçlanan Aksiyon Senaryosu:

• HTTP Webhook Çalıştır: Alt akışı durdur ("Line1.Conveyor.FeedCommand" komutu)
• MQTT Çıktısı Çalıştır: "ProxusMfg/Line1/alerts/TemperatureSpike" konusuna yayınla
• Entegrasyon Çalıştır: SAP bildirimi oluştur "Bakım Emri - Termal limit aşıldı"
• Bildirim Çalıştır: Slack mesajı gönder "@production_team Sıcaklık nedeniyle besleme durduruldu"

İleri Düzey Mühendisler için Korumalı C# Script Motoru

Sahadaki dinamikler her bir PLC için "Eğer sıcaklık > 10" sularından çıkıp, karmaşık bir yapay zeka çıkarımı, matematik dizileri, for loop dönüşlerine evrildiği noktada, görsel araçlar çöp olur. Proxus, işte bu noktada direkt olarak mühendislere "C# Script" yazım olanağı tanır.

Neden Başka Dil Değil de Native C#?

• Alışkanlık ve Literatür: Modern OT teknisyenleri, SCADA ve yazılım mühendisleri .NET teknolojilerini fabrikalarda yoğun kullanır.
• Güvenlik: String yerine int istenilen durumlarda derleyici sizi henüz makineyi kilitlemeden engeller ve büyük fabrikasyon çökmelerin önüne geçeriz.
• JIT Compiler Hızı: Kod satırlarınız yorumlayıcıyla işlenmez; Proxus'ta yazdığınız bu betikler doğrudan en saf format olan makine diline çevrilir..

Gerçek Hayat Senaryosu: Makine Öğrenimi (ML) Kestirimci Bakım Algoritması

// Proxus Edge SDK: Kestirimci Bakım Fonksiyonu
public class KestirimciBakim : FunctionBase {

 public KestirimciBakim(object sys, object log, object cfg)
 : base(sys, log, cfg) { }

 protected override void OnStarted() {
 Subscriptions?.Add(new SubscriptionContext {
 Type = typeof(TransportData),
 Topics = (HashSet<string>) ["*"]
 });
 // Geçmiş analizi için zaman pencereli önbellek
 EnableCacheWithExpirationTime = TimeSpan.FromHours(1);
 base.OnStarted();
 }

 protected override void OnMessageReceive(FunctionContext ctx) {
 if (ctx.Message is TransportData data) {
 var titresim = data.GetPayloadValueByName<double>("Vibration");
 var sicaklik = data.GetPayloadValueByName<double>("Temperature");

 // Önbellekteki son 30 dakika verisinden trend analizi
 var ortSıcaklık = Cache
 .Where(kv => kv.Key >= DateTime.Now.AddMinutes(-30))
 .Select(kv => kv.Value)
 .SelectMany(t => t.Payload)
 .Where(p => p.Key == "Temperature")
 .Select(p => Convert.ToDouble(p.Value))
 .DefaultIfEmpty(0)
 .Average();

 if (titresim > 4.5 && sicaklik > ortSıcaklık * 1.3) {
 PublishMqttMessage(
 "alert/motor_ariza_riski",
 $"Titreşim: {titresim}, Sıcaklık: {sicaklik}°C");
 LogError(
 $"Motor arıza riski tespit edildi. Skor: {titresim * sicaklik:F0}");
 }
 }
 base.OnMessageReceive(ctx);
 }
}

Otomatik Hata Sandboxing'i (Korumalı Kum Havuzu)

Normalde standart bir IIoT gateway veya uygulamanın içerisine gömdüğünüz böyle bir script çatlarsa (hata verirse), gateway komple arıza verebilir, fabrika verisi kopar. Proxus yazdığınız C# kodunu izole bir ortamda "Sandbox" modelinde çalıştırır.

• Döngü Sınırlandırması: Sistem maksimum yürütme süresi verir. Kötü bir "while(true)" yazsanız bile kural saniyeler içinde otomatik sonlandırılır (Kill işlemi)
• Düşük Bellek Tahsisi (Low-Allocation): Saniyede yüzlerce milisaniye frekansta okunması gereken satırlar belleğin şişmesine (RAM Overload) neden olabilir. Uyguladığımız "ArrayPool" mimarisiyle hafıza optimize edilerek RAM üzerindeki çöp toplayıcı (GC) baskısı minimumda tutulur.

100.000 (yük, donanım ve topoloji koşullarında)+ Kuralı "Actor" Mimarisi ile Yönetmek

Sistemlerin neden bu kadar performanslı olabildiğinin arkasında "Actor-Based Concurrency" modeli yatar. Eski tip sistemlerde Thread yönetimleri ve obje (Object) kilitlemeleri vardır. Biri kilitlendiğinde diğer kurallar sırasını bekler; tıkanıklık oluşur. Proxus modelinde ise her Kural Scripti kendi "Actor" baloncuğunda bağımsız yaşar. Hiçbiri bir diğerinin kuyruğuna bağlı değildir (Non-Blocking).

• Akıllı RAM Tamponlaması (In-Memory Cache): Sistemin "Sıcaklık" tagini her saniye gidip PLC'den okuyup işlemciyi sömürmesini engelleriz. Değer yalnızca fiziken değiştiği milisaniye (MQTT Push/Publish Event) ön belleğe itilir ve o milisaniye kural işlemcisi uyandırılarak aksiyon aldırılır. O ana kadar sistem uyur (CPU Cycle tüketimi sıfırdır).

Git Tarzı Versiyonlama ve Test Güvenliği

Sahada, üretimi durdurma veya motor komutunu doğrudan etkileyen agresif aksiyonlar barındıran kuralı (Script) değiştirmek korkutucudur. Bu yüzden kuralların Otomatize Versiyon Kontrol Sistemi vardır:

1. Yazılım Aşaması: Kuralları arayüzden yazarsınız.
2. Gölge Testleri: Sisteminizi aktif etmeden önce belirli sanal Test Gateway'lerinde mevcut MQTT data akışıyla "deneme / simülasyon" koşturursunuz.
3. Onaylama: Uygulama loglarını, false-alarm (hatalı alarm) oranını ölçer ve yönetim onayı alırsınız.
4. Deploy: Canlıya basarsınız (İstenilen bir bakım saati gecesinde yapılabilir).
5. Rollback (Geri Alma): Bir terslik varsa tek tıkla eski versiyona 1 milisaniye içinde dönüş yapabilirsiniz.

Ne zaman uygun olmayabilir?

• Düşük frekanslı telemetride daha basit yaklaşımlar yeterli olabilir.
• Tek hatlı küçük tesislerde tam dağıtık mimari maliyet-etkin olmayabilir.
• Katı legacy kısıtları olan ortamlarda kademeli geçiş gerekebilir.
• Emniyet-kritik kapalı çevrim kontrol, PLC/Safety PLC katmanında kalmalıdır.

Gözlenen performans, yük deseni ve dağıtım mimarisine göre farklılaşabilir.

Sık Sorulan Sorular

Görsel Kural Oluşturucu ile C# scripting'i ne zaman kullanmalıyım?

Kuralların %80'i için görsel oluşturucuyu kullanın: basit eşik alarmları, bildirimler, temel koşullu yazma ve zamanlanmış tetikleyiciler. Bunlar IF-THEN ile ifade edilebilen kurallardır. C#'a şu durumlarda geçin: farklı PLC'ler arası çok cihazlı korelasyon, durum bilgili hesaplamalar (hareketli ortalamalar, pencere bazında değişim hızları), harici HTTP API çağrıları veya makine öğrenimi model entegrasyonu. Birçok ekip görsel başlar ve ihtiyaç büyüdükçe belirli dalları C#'a taşır.

Edge kural değerlendirmesinden ne kadar gecikme beklemeliyim?

IL'ye derlenen görsel kurallar için tipik ARM/x64 edge donanımında tag değişiminden aksiyon yürütmeye kadar 5ms altı değerlendirme süresi beklenir. C# scriptleri karmaşıklığa bağlı olarak marjinal ek yük ekler. Güvenlik açısından kritik kurallar genellikle harici çağrılara bağlı olmamalıdır; bunları lokal ve deterministik tutun.

Kuralları üretime etki etmeden nasıl test ederim?

Proxus aşamalı dağıtımı destekler: Kural v2'yi canlı gölge veriyle çalışan bir Test Gateway'e dağıtın (üretimle aynı MQTT topic'lerine abone, ancak aksiyonlar devre dışı veya test namespace'ine yönlendirilmiş). v2'yi belirli bir süre (tipik 3–7 gün) izleyin. Ancak doğrulamadan sonra üretim gateway'lerine promote edin.

Kurallar OPC UA veri kaynaklarında tetiklenebilir mi?

Evet. Kural motoru, kaynak protokolünden bağımsız olarak Birleşik İsim Alanı içindeki tag'ler üzerinde çalışır. OPC UA tag'i, Proxus Edge Gateway aracılığıyla UNS'e eşlenmişse, Modbus, S7 veya yerel MQTT tag'leriyle aynı seviyede birinci sınıf tetikleyici olur.

Kurallar birden fazla Edge Gateway arasında nasıl senkronize edilir?

Kurallar merkezi Proxus Platform'da yazılır ve belirli Edge Gateway'lere dağıtılır. Her gateway kuralları kendi lokal tag setine karşı bağımsız değerlendirir - dağıtık konsensüs protokolü yoktur ve bu kasıtlıdır: güvenlik açısından kritik kararlarda ağa bağımlı gecikmeyi önler. Tesisler arası korelasyon (örn: OEE karşılaştırması) için her gateway'in yayınladığı toplu UNS topic'lerine abone olan merkezi kurallar kullanın.

Sonuç: Kural Kodları Yan Ürün Değil, Kalbin Kendisidir

Çoğu endüstriyel platformda, kural motoru "Evet bir de grafiğin kenarına basit alarm ekleyebilirsiniz" diyen ucuz bir eklentidir. Proxus mimarisinde ise kurallar Üretim Tesisinin Kalbidir: versiyonlanabilir, güvenli, testleri yapılmış ve lokalize odaklı.

Kaynaklar

1. IEC 61131-3 - PLC programlama dilleri uluslararası standardı, endüstriyel kural motoru tasarımına ilham veren structured text (ST) ve FBD kalıpları. IEC 61131
2. Charles Forgy, "Rete: Çoklu Örüntü/Nesne Eşleme Problemi İçin Hızlı Algoritma" (1982) - Birçok üretim kural sisteminin temelindeki algoritma.
3. Carl Hewitt, "Yapay Zeka İçin Evrensel Modüler Aktör Formalizmi" (1973) - Proxus kural yürütme motorunun kullandığı Aktör Modeli'nin matematiksel temeli.
4. OPC Foundation - OPC UA Alarms & Conditions - Kural motoru tetikleyicileri için ilgili endüstriyel alarm yönetim spesifikasyonu. opcfoundation.org

Proxus Kural Motoru'nun mimarinize nasıl entegre olduğunu Edge Computing Patterns rehberimizden okuyun veya kuralların IT/OT yakınsaması ve kestirimci bakım iş akışlarını nasıl yönlendirdiğini keşfedin.