Endüstriyel otomasyon için kural motoru tasarımı

Endüstriyel kural motoru, makinelerden gelen anlık veriyi izler ve belirlenen koşullar gerçekleştiğinde işlem yapar: alarm üretir, bir değer yazar veya iş akışı başlatır. Zor olan, kural sayısı arttığında sistemi yönetmek, farklı cihazların verilerini birlikte değerlendirmek, yük altında kararlı çalışmak ve değişiklikleri güvenle devreye almaktır. Bu rehber bunları sırayla ele alıyor, örnek bir karar mantığı gösteriyor ve kodsuz ifade kuralları ile C# fonksiyonlarının nasıl birlikte kullanılacağını anlatıyor.

Fabrikanızla birlikte büyüyen bir kural motoru tasarlamak

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

"Bu veri noktası şu değeri geçerse alarm gönder."

Sorun şu ki gerçek fabrikalar nadiren burada durur. Kısa süre içinde ekipler süre kontrolleri, vardiyaya bağlı koşullar, duruma göre istisnalar, cihazlar arası ilişkilendirme, ERP ve CMMS eylemleri ve kural değişikliklerinin güvenle devreye alınmasını ister. Pilot projede iş gören bir kural motoru, bu ihtiyaçlar biriktikçe işletilmesi zor bir yapıya dönüşebilir.

Bu yazı, üretimde çalışacak bir endüstriyel kural motorunun ardındaki tasarım kararlarına odaklanıyor: kuralların nasıl yazıldığı, nasıl çalıştırıldığı, nasıl doğrulandığı ve işletme güvenliği için nerede sınır çizildiği. Ulaşılabilecek işlem hacmi ve gecikme, iş yükünün niteliğine, kuralların karmaşıklığına ve donanıma göre değişir. Değerlendirmenin yerelde kalması ya da dış sistemlere bağlı olması da sonucu etkiler.

• Karma yazım modeli: Bildirimsel kurallar, ileri senaryolar için de kod
• Yerel çalışma: Kararlar Edge Gateway'de kaldığında daha düşük gecikme
• İşletme güvenceleri: İnceleme, test ve geri alma disiplini şart

Sonuçlar iş yükü profiline, donanım kapasitesine ve kurulum yapısına bağlıdır.

Geleneksel kural motorlarının sorunu

Mesele tek bir eşik olmaktan çıktığında kural motorları zorlaşmaya başlar.

Zorluk 1: Kapsamın büyümesi

Basit bir alarm çoğu zaman durum takibi yapan bir kurala dönüşür:

• koşul belirli bir süre devam ederse alarm vermek
• ayar ya da bakım zamanlarında alarmı bastırmak
• daha sert bir sınır aşıldığında hemen üst kademeye bildirmek

Zorluk 2: Cihazlar arası bağlam

Endüstriyel kararların çoğu birden fazla sinyale dayanır. "A makinesi ısındı" bilgisi tek başına yetmez. Kuralın hattın durumunu, önceki istasyonun çalışıp çalışmadığını, sonraki istasyondaki yığılmayı ya da bir iş sisteminden gelen iş emri bilgisini de bilmesi gerekebilir.

Zorluk 3: Yük ve öngörülebilirlik

Cihaz ve kural sayısı arttıkça sorgulama, ortak durumu tekrar tekrar kontrol etme ve dış sistemleri çağırma maliyeti hızla büyür. Sık veritabanı sorgularına ya da geniş çaplı yeniden hesaplamalara dayanan bir tasarım, telemetri ani dalgalar hâlinde geldiğinde genellikle performans kaybeder.

Zorluk 4: Değişiklik yönetimi

Üretimdeki kuralların bir yaşam döngüsü olmalıdır. Ekiplerin genellikle taslak kurallara, aşamalı doğrulamaya, belirli Edge Gateway'lere kademeli geçişe ve yanlış alarmlar ya da istenmeyen yazmalar ortaya çıktığında net bir geri alma yoluna ihtiyacı vardır.

Proxus'un yaklaşımı kurallar, işlem akışları ve fonksiyonlar üzerine kurulu

Proxus bu işi, sınırları net çizilmiş birkaç araca böler. Hepsi merkez sunucuda yapılandırılır ve Edge Gateway'lerde çalışır. (Ekibiniz bu mantığı bugün Node-RED'de kuruyorsa, Proxus ve Node-RED karşılaştırması bir akış araç setini kontrollü bir platformla karşılaştırıyor.)

İfade ve anomali kuralları (kodsuz)

Alarm kuralları, mantık açık, sınırlı ve kolay incelenebilir olduğunda işe yarar:

• eşikler ve koşullar için ifade kuralları
• Z-skoru, IQR, hareketli ortalama, değişim hızı, sapma (drift), düz çizgi (flatline) ve veri boşluğu tespiti için anomali kuralları
• gerçek zamanlı ya da zamanlanmış değerlendirme
• alarm ve bildirim gibi kural eylemleri

Kurallar uçta çalışır ve ağ kesildiğinde de çalışmaya devam eder. Avantaj yalnızca kolay erişilebilirlik değildir: bildirimsel bir kuralı, devreye alınmadan önce işletme, otomasyon ve yazılım ekiplerinin birlikte incelemesi de daha kolaydır. İşlem akışları kuralların etrafındaki veri düzenleme işini (dönüştürme, ölçekleme, yeniden adlandırma, filtreleme, yönlendirme) üstlenir ve karşılaştırılabilir revizyonlar saklar; böylece bir değişiklik önceki sürümle yan yana incelenebilir.

İleri senaryolar için C# fonksiyonları

Bazı durumlar gerçekten kod gerektirir. Proxus'ta bu kod, Proxus SDK ile yazılan, merkez sunucuda derlenip dağıtılan bir C# fonksiyonudur:

• belirli bir zaman aralığında birden fazla cihazın verisini ilişkilendirmek
• türetilmiş durum hesaplamaları
• istatistiksel yumuşatma ya da anomali puanlaması
• iç içe görsel koşullarla ifade etmesi zahmetli dönüşümler

Buradaki temel tasarım ilkesi "her yerde kod" değildir. Kod, yalnızca görsel modelin anlaşılması mantığın kendisinden daha zor hâle geldiği yerlerde kullanılır.

Örnek karar kalıbı

Mantık ister görsel olarak ister kodla yazılsın, karar yolu yine de bir işletme talimatı gibi okunmalıdır:

IF temperature exceeds the warning threshold
AND the machine is in production mode
AND the condition persists for the configured duration
AND the line is not in a scheduled maintenance window
THEN publish an event, notify operations, and optionally create a maintenance task

Bu tür bir talimatı doğrulamak, çalışma zamanı nesneleri ve SDK çağrılarıyla dolu bir koddan çok daha kolaydır.

Tek ve ortak bir çalışma modeli

Ortak bir çalışma ortamının asıl mimari değeri, işletmede tutarlılık sağlamasıdır. Ekipler bildirimsel kurallar için bir dağıtım modeli, kod için de başka bir model öğrenmek zorunda kalmamalıdır.

Uygulamada ölçeklenebilirlik birkaç etkene bağlıdır:

• kuralı tetikleyen veri noktalarının ne sıklıkla değiştiği
• kuralın bellekteki yerel durumla mı çalıştığı, yoksa dış sistemlere erişmesi mi gerektiği
• kuralın cihaz bazında mı, hatlar arası mı, tesisler arası mı olduğu
• çıktının yerel bir olay mı, MQTT sunucusuna bir yayın mı, yoksa uzak bir API çağrısı mı olduğu

Yerelde kalan ve zaten anlamlandırılmış telemetri üzerinde çalışan kurallar, eşzamanlı olarak uzak sistemleri bekleyen kurallara göre genellikle daha iyi ve daha öngörülebilir performans gösterir.

Bu yüzden uygulamadaki hedef basittir:

• kritik değerlendirme yolunu yerelde tutmak
• durum değişikliklerini tekrar tekrar sorgulamak yerine yayınlamak
• anlık karar verme işini ağır geçmiş veri analizlerinden ayırmak
• maliyetli entegrasyonları, ana kural döngüsünü kilitlemeyecek şekilde yalıtmak

Doğrulama, devreye alma ve güvenlik sınırları

İşletme modeli en az kural sözdizimi kadar önemlidir.

Doğrulama süreci

Sahada işe yarayan bir süreç genellikle şu adımları içerir:

1. kuralı merkezde yazmak
2. test verisiyle ya da deneme modunda çalıştırmak
3. alarmların kalitesini ve yanlış alarmları incelemek
4. kuralı seçilen Edge Gateway'lere almak
5. daha önce onaylanmış sürüme dönüş yolunu açık tutmak

Bu, özellikle bakım iş emri oluşturan ya da sonraki sistemlerde yazma yapabilen eylemleri tetikleyen kurallar için önemlidir.

Emniyet sınırları

İyi tasarlanmış bir kural motoru bile her türlü endüstriyel mantığı üstlenmemelidir.

• Emniyet PLC'sinin mantığı emniyet katmanında kalır.
• Katı gerçek zamanlı kilitlemeler (interlock) deterministik kontrol katmanlarında kalır.
• Kurumsal sistemlere dönük koordinasyon, durum izleme ve alarm üretimi, Edge Gateway'deki bir kural motoru için daha uygun adaylardır.

Siber güvenlik sınırları

Kod yazma desteği varsa, bu kod kontrollü çalışma sınırları içinde, açık bir incelemeden geçerek ve sınırlı yetkilerle çalışmalıdır. Bunu anlatmak için tanıtım içeriklerinde iç sınıf adlarını ya da çalışma zamanı sınırlarını açıklamaya gerek yoktur; önemli olan, kullanıcının yazdığı mantığın incelenebilir, test edilebilir ve sınırlandırılmış olmasıdır.

Karmaşık bir kural motoru ne zaman gereksiz olabilir?

Deneyimlerime göre kural motorları bazen eldeki soruna göre fazla büyük tasarlanıyor. Aşağıdaki durumlarda daha sade mimarileri değerlendirin:

• Katı gerçek zamanlı emniyet kontrolü: Emniyet açısından kritik bir acil durdurma ya da kablolu bir kilitleme, ne kadar sağlam olursa olsun bir kural motoruna bağlı olmamalıdır. Bu kararlar, hiçbir yazılıma bağımlı olmayan, kablolu bağlantılı sertifikalı emniyet PLC'lerinde kalmalıdır.
• PLC içinde çözülebilen basit mantık: Otomasyon ihtiyacınızı PLC'nin kendi mantığı (boolean koşullar, zamanlayıcılar, sayaçlar) yeterince karşılıyorsa, bir kural motoru eklemek gereksiz işletme karmaşası ve bakım yükü getirir.
• Tek varlığı ve tek ölçütü olan tesisler: 3-5 basit eşik alarmı olan bir fabrikada, eksiksiz bir kural motoru platformunun yönetim yükü kendini amorti etmeyebilir. Basit bir SCADA alarmı yeterli olabilir.
• Olgunlaşmamış ya da kararsız veri kaynakları: Veri noktalarınız tutarlı biçimde erişilebilir değilse, adlandırma kuralları karmakarışıksa ya da veri kalitesi düşükse, kural motoru sorunu çözmek yerine hayal kırıklığını büyütür. Önce UNS'inizi oturtun; adlandırma ve kalite kuralları Unified Namespace kurulum rehberi yazısında anlatılıyor.

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.

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

Sık sorulan sorular

İfade kurallarını ne zaman, C# fonksiyonlarını ne zaman kullanmalıyım?

Mantık eşikler, bildirimler, zamanlanmış tetikleyiciler ve sınırları belli koşullu iş akışları olarak açıkça ifade edilebiliyorsa ifade ve anomali kurallarını kullanın. Birden fazla cihazın ilişkilendirilmesi, durum tutan hesaplamalar, dış çağrılar ya da özel kütüphaneler gerekiyorsa kod kullanın. Seçimi varsayılan bir yüzdeye göre değil, her kural için test edilebilirliğe, inceleme sorumluluğuna, dağıtım kontrollerine ve hatanın doğuracağı etkiye göre yapın.

Uçta kural değerlendirmesinde ne kadar gecikme beklemeliyim?

Gecikme öncelikle kuralın ne kadar veriye dokunduğuna ve çalışma yolunun yerelde kalıp kalmadığına bağlıdır. Edge Gateway'de yerel çalışan basit bir eşik ya da süre kuralı hızla değerlendirilebilir; dış bir HTTP uç noktasını bekleyen bir kural ise ağ gecikmesini ve karşı sistemin değişkenliğini de devralır. Acil durdurma gibi emniyet açısından kritik kurallar deterministik PLC ya da emniyet PLC'si katmanlarında kalmalıdır; Edge Gateway'deki kurallar izleme, koordinasyon ve kurumsal sistemlere dönük eylemler için daha uygundur.

Kuralları üretimi etkilemeden nasıl test ederim?

İşe yarayan bir yöntem, yeni kuralı önce aynı kaynakları okuyan bir test Edge Gateway'inde çalıştırmak ve eylemlerini vardiyadaki ekip yerine bir test kanalına yönlendirmektir. Kuralın üreteceği alarmları, prosesin olağan döngüsünü (vardiyalar, ürün değişimleri, hafta sonları) kapsayacak kadar uzun süre izleyin, ardından kuralı canlıya alın. Proxus'ta yapılandırma değişiklikleri değişiklik geçmişine kaydedilir, işlem akışları karşılaştırılabilir revizyonlar saklar ve Trend çalışma alanı kaydedilen alarm anlarını değerlerin yanında gösterir. Şuna dikkat edin: burada gerçekten tetiklenmiş alarmlar görünür; yeni bir algılayıcı geçmiş veri üzerinde yeniden çalıştırılmaz. İstisna, asistan üzerinden önerilen bir kuraldır: siz onaylamadan önce asistan kuralı kayıtlı veride dener ve kaç kez tetikleneceğini gösterir (Yapay Zekâ Asistanı ve ajan erişimi).

Kurallar OPC UA veri kaynaklarıyla tetiklenebilir mi?

Evet. Kural motoru, veri noktaları hangi protokolden gelirse gelsin, Unified Namespace içindeki veri noktaları üzerinde çalışır. Bir OPC UA veri noktası Proxus Edge Gateway'i üzerinden UNS'e eşlendiğinde, tıpkı Modbus, S7 ya da doğrudan MQTT veri noktaları gibi kuralı tetikleyebilir. Kural, verinin hangi protokolden geldiğini bilmez ve bununla ilgilenmez.

Kurallar birden fazla Edge Gateway arasında nasıl eşitlenir?

Kurallar merkez sunucuda yazılır ve belirli Edge Gateway'lere gönderilir; Edge Gateway kendine ait bir yapılandırma tutmaz. Her Edge Gateway kendi kurallarını kendi yerel veri noktaları üzerinde bağımsız olarak değerlendirir. Dağıtık bir uzlaşma protokolü yoktur ve bu bilinçli bir tercihtir: bir karar ağı beklemez, bağlantı koptuğunda kurallar çalışmaya devam eder. Tesisler arası karşılaştırma (örneğin tesisler arası OEE) için, her tesisin verisinin zaten toplandığı merkez sunucudaki geçmiş veri deposu ve panolar üzerinden çalışın.

Kurallar birer üretim varlığıdır

Proxus'ta otomasyon kuralları, bir görselleştirme aracına sonradan eklenmiş bir özellik değildir. Kurallar birer mühendislik varlığıdır: merkezde tanımlanır, ihtiyaç duyan Edge Gateway'lere gönderilir, değişiklik geçmişine kaydedilir ve uçta çalışır. Bu sayede ağ kesintilerinde de çalışmaya devam eder.

İhtiyacınız basit bir eşik alarmı da olsa, birkaç sinyali ilişkilendiren bir C# fonksiyonu da olsa, her kurala aynı şekilde yaklaşın: kuralı yazıya dökün, gerçek veriyle test edin ve önceki sürümü hazırda tutun.

Kaynaklar

1. IEC 61131-3: PLC programlama dilleri için uluslararası standart. Endüstriyel kural motoru tasarımına ilham veren yapısal metin (ST) ve fonksiyon blok diyagramı (FBD) kalıplarını tanımlar. IEC 61131
2. Charles Forgy, "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem" (1982): Pek çok üretim kuralı sisteminin temelindeki algoritma; kural değerlendirme performansını anlamak için önemlidir.
3. Carl Hewitt, "A Universal Modular Actor Formalism for Artificial Intelligence" (1973): Eşzamanlı kural çalışma ortamlarının yaygın temeli olan Actor modelinin matematiksel temeli.
4. OPC Foundation, OPC UA Alarms & Conditions: OPC UA üzerinden endüstriyel alarm yönetimi spesifikasyonu; kural motoru tetikleyicileri için bir veri kaynağı olarak önemlidir. opcfoundation.org

Proxus kural motorunun mevcut mimarinize nasıl uyduğunu görmek için uç bilişim kalıpları rehberimizi okuyun ya da kuralların IT/OT yakınsamasını ve kestirimci bakım süreçlerini nasıl yürüttüğüne göz atın.