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

Endüstriyel kural motorları genellikle basit bir ihtiyaçla başlar:

"Bu tag eşik değeri aşarsa uyarı ver."

Gerçek saha ihtiyaçları ise çok hızlı büyür. Kısa süre sonra ekipler; süre koşulları, vardiya pencereleri, bakım istisnaları, çapraz cihaz korelasyonu, ERP/CMMS aksiyonları ve güvenli dağıtım mekanizması istemeye başlar. Pilot aşamada çalışan bir yapı, bu gereksinimler biriktiğinde işletmesi zor bir sisteme dönüşebilir.

Bu yazının odağı, üretimde kullanılacak bir kural motorunun mühendislik tercihleri: yazım modeli, yürütme modeli, doğrulama akışı ve güvenlik sınırları. Elde edeceğiniz gecikme ve kapasite; iş yükünün şekline, kural karmaşıklığına, donanıma ve kararın yerelde mi yoksa uzak sistem bağımlılığıyla mı çalıştığına göre değişir.

Sonuçlar topolojiye, donanıma ve iş yükü profilinize göre değişir.

Geleneksel Sistemler Neden Zorlanır?

Kural motorlarını zorlaştıran şey tek bir eşik değildir; kapsamın büyümesidir.

Kapsam Büyümesi

Basit bir alarm kısa sürede durum bilgili bir politikaya dönüşür:

• koşul belirli bir süre devam ederse alarm ver
• bakım veya setup sırasında alarmı bastır
• daha sert limitte doğrudan eskalasyon yap

Çapraz Cihaz Bağlamı

Birçok karar tek bir sinyalle alınmaz. "Makine sıcak" bilgisi yetmez; hattın durumu, upstream/downstream akışı veya iş emri bağlamı da gerekebilir.

Yük ve Tutarlılık

Cihaz ve kural sayısı arttıkça sürekli sorgulama, paylaşımlı durum yönetimi ve uzak sistem çağrıları pahalılaşır. Her tetikte veritabanına giden veya geniş bir veri kümesini tekrar hesaplayan tasarımlar, ani yük altında gecikme ve kuyruk birikimi üretir.

Değişiklik Yönetimi

Üretim mantığı bir yaşam döngüsü ister. Ekipler genellikle taslak kural, gölge test, seçili gateway’lere dağıtım ve problem olduğunda kontrollü geri dönüş ister.

Proxus Yaklaşımı: Görsel ve Kodun Aynı Operasyon Modelinde Buluşması

Proxus bu ihtiyacı iki yazım tarzıyla ele alır; ancak operasyon modeli tek kalır.

Görsel Kriter Oluşturucu

Görsel kurallar şu tip durumlarda değerlidir:

• eşik bazlı alarmlar
• vardiya veya zaman planına bağlı bildirimler
• temel koşullu yazmalar
• MQTT, webhook veya ticketing sistemlerine yönlendirme

Buradaki ana avantaj sadece kullanım kolaylığı değildir. Görsel kural; operasyon, otomasyon ve yazılım ekiplerinin birlikte gözden geçirebileceği daha açıklanabilir bir ifade biçimi sunar.

C# Scripting ile Gelişmiş Senaryolar

Bazı senaryolar gerçekten kod ister:

• zaman penceresi içinde çoklu cihaz korelasyonu
• türetilmiş durum hesapları
• istatistiksel yumuşatma veya anomali skoru
• görsel modelde okunması zorlaşan dönüşümler

Mühendislik ilkesi şudur: Her şeyi kodla yapmak değil, görsel modelin okunabilirliğini bozduğu noktada kodu devreye almak.

Örnek Karar Deseni

Kural ister görsel ister script ile yazılsın, operasyon politikası şu sadelikte okunabilmelidir:

EĞER sıcaklık uyarı eşiğini aşarsa
VE makine üretim modundaysa
VE koşul tanımlı süre boyunca devam ederse
VE hat planlı bakım penceresinde değilse
O ZAMAN olay yayınla, operasyonu bilgilendir ve gerekirse bakım görevi oluştur

Bu tür bir ifade, public içerikte iç runtime nesneleri veya SDK sınıfları göstermeden de güçlü biçimde anlatılabilir.

Tek Bir Yürütme Modeli Neden Önemlidir?

Asıl mimari değer, görsel ve script tabanlı kurallar için farklı bir operasyon modeli öğretmek zorunda kalmamaktır.

Pratikte ölçeklenebilirliği belirleyen ana etkenler şunlardır:

• tetikleyici tag’lerin ne sıklıkla değiştiği
• kuralın yerel bellekteki bağlamsallaştırılmış veriyle mi, yoksa uzak sistemlerle mi çalıştığı
• kuralın cihaz bazlı mı, hat bazlı mı, çoklu tesis bazlı mı olduğu
• çıktının yerel olay mı, broker yayını mı, yoksa uzak API çağrısı mı olduğu

Yerelde çalışan ve mevcut telemetri bağlamını kullanan kurallar, uzak bağımlılığı olan kurallara göre genellikle daha öngörülebilir davranır.

Bu nedenle pratik hedef nettir:

• kritik değerlendirme yolunu mümkün olduğunca yerelde tutmak
• sürekli polling yerine olay veya durum değişimi ile çalışmak
• canlı karar alma ile ağır tarihsel analitiği ayırmak
• pahalı entegrasyonları ana kural döngüsünden izole etmek

Doğrulama, Dağıtım ve Güvenlik Sınırları

Kural motorunda operasyon modeli, söz dizimi kadar önemlidir.

Doğrulama Akışı

Gerçekçi bir endüstriyel akış genellikle şunları içerir:

1. kuralı merkezi ortamda oluştur
2. test veya gölge veriyle çalıştır
3. false-positive ve alarm kalitesini incele
4. seçili gateway’lere promote et
5. önceki onaylı sürüme geri dönebilecek yol bırak

Özellikle bakım iş emri oluşturan veya yazma etkisi doğuran kurallarda bu disiplin kritik önemdedir.

Emniyet ve Kontrol Sınırları

İyi tasarlanmış bir kural motoru bile her mantığı kendi içine almamalıdır.

• Safety PLC mantığı safety katmanında kalır.
• Sert gerçek zamanlı interlock kararları kontrol katmanında kalır.
• Gateway kural motoru; izleme, orkestrasyon, bakım tetikleme ve kurumsal entegrasyon için daha uygundur.

Güvenlik Sınırları

Script desteği varsa; kontrollü yetkiler, gözden geçirilebilir dağıtım ve sınırlandırılmış yürütme ilkeleriyle çalışmalıdır. Public blog içeriğinde iç sınıf isimlerini veya runtime limitlerini açmak gerekmez; önemli olan kullanıcı mantığının test edilebilir, gözden geçirilebilir ve sınırlandırılmış olmasıdır.

Karmaşık Kural Motoru Ne Zaman Fazla Olur?

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?

Gecikme; kuralın ne kadar veri dokunduğuna ve karar yolunun yerelde mi yoksa uzak sistem bağımlılığıyla mı çalıştığına göre değişir. Basit yerel eşik ve süre kuralları genellikle hızlı değerlendirilir; harici HTTP çağrısı gibi bağımlılıklar ise ağ ve hedef sistem gecikmesini devreye sokar. Emniyet-kritik kararlar gateway katmanında değil, deterministik PLC veya Safety PLC katmanında kalmalıdır.

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ç: Kuralları Üretim Varlığı Gibi Yönetmek

Kural motoru yalnızca alarm üretmek için kullanılan yan bir özellik değildir. Doğru tasarlandığında; gözden geçirilebilir, test edilebilir, kademeli dağıtılabilir ve gerektiğinde geri alınabilir bir üretim mantığı katmanına dönüşür. Sağlam yaklaşım; görsel kuralların açıklanabilirliğini, gerektiğinde script ile gelen esnekliği ve tüm bunların üstündeki operasyon disiplinini birlikte kurmaktır.

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.