Olay Grafikleri: Tekil Alarmlardan Nedensellik Zincirine

Olay grafiği (event graph) yaklaşımıyla kök neden analizi: birbirine bağlı olayların zincir hâlinde yorumlanması.

Yazar: CX Teknoloji Uzman Ekibi

Olay grafiği, kameraların ve sensörlerin ürettiği tekil alarmları düğüm, bunlar arasındaki zamansal ve mekânsal yakınlığı kenar olarak modelleyen bir yapıdır. Sistem bu ağda sık tekrarlayan zincirleri bulur ve kök neden hipotezi olarak sunar. Böylece İSG ya da üretim ekibi yüzlerce ayrı alarm yerine birkaç tekrar eden deseni inceler; iyileştirme belirtiye değil nedene yönelir.

Tekil alarmlar sahayı anlatmaz. "Forklift hız ihlali", "koridorda malzeme", "yaya ihlali" alarmları ayrı ayrı okunduğunda üç sorun görünür; birlikte okunduğunda tek bir kök neden çıkar: koridor tıkalı olduğu için forklift alternatif rotadan hızla geçiyor ve yaya yolunu kesiyor.

Grafik yapısı

Her olay bir düğüm, zamansal ve mekânsal yakınlık ise kenar olur. Sistem tekrarlayan alt-desenleri arar; sık görülen zincirler kök neden hipotezi olarak raporlanır. İSG ekibi tek tek alarm değil, desen okur.

Bir düğüm; olay tipini, kamerayı, bölgeyi, zamanı ve varsa makine durumunu taşır. İki olay arasındaki kenar, belirli bir zaman penceresi içinde ve birbiriyle ilişkili bölgelerde gerçekleşmeleriyle kurulur; pencere uzunluğu ve bölge komşulukları sahaya göre tanımlanır. Tek başına bir kez görülen bir zincir tesadüf olabilir. Anlamlı olan, aynı sıranın farklı günlerde ve vardiyalarda tekrar etmesidir. Bu yüzden sistem bir zinciri ancak yeterince tekrar ettiğinde hipotez olarak öne çıkarır ve her hipotezin arkasındaki olay kliplerini de listeler.

Grafiğin okunması da tasarımın parçasıdır. Ekrana yüzlerce düğüm dökmek, alarm listesinden farksızdır. Bunun yerine sistem, dönem içinde en sık tekrarlayan birkaç zinciri, her birinin kaç kez görüldüğünü, hangi bölgede ve hangi vardiyada yoğunlaştığını özetler. Her zincirden bir örnek olay klibine tek tıkla ulaşılabilir. İSG toplantısında tartışılan şey böylece “bu hafta kaç ihlal oldu” değil, “bu zincir neden tekrar ediyor ve kim neyi değiştirecek” olur.

Korelasyon nedensellik değildir

Grafik “A olayından sonra sık sık B olayı geliyor” der; “A, B'ye neden oluyor” demez. Bu ayrımı ürün tasarımına yansıtıyoruz: sistem kök nedeni ilan etmez, hipotez önerir. Hipotezi doğrulayan ya da reddeden, sahayı bilen insandır. Koridor örneğinde doğrulama basittir: klipler izlenir, koridor boşaltıldığı günlerde hız ihlalinin azalıp azalmadığına bakılır. Müdahale sonrası desenin zayıflaması, hipotezin en güçlü kanıtıdır. Bu döngü, ekibin sistemin önerilerine körü körüne değil, kanıtla güvenmesini sağlar.

Yanıltıcı zincirlerin tipik kaynağı ortak nedendir. Vardiya değişiminde hem koridorda malzeme birikir hem de yaya trafiği artar; iki olay birbirini tetiklemediği hâlde grafikte bağlı görünür. Asıl neden, ikisini de üreten devir teslim düzenidir. Bu yüzden grafiğe vardiya saatleri, sevkiyat takvimi ve bakım planı gibi bağlam bilgileri de eklenir; sistem bir zinciri önerirken bu bağlamı da gösterir. Ekip, zincirin mi yoksa arkasındaki ortak koşulun mu değiştirilmesi gerektiğine bu bilgiyle karar verir.

Yanlış alarm ve gürültü

Olay grafiği ancak girdisi kadar iyidir. Yanlış alarmlarla dolu bir akış, var olmayan zincirler üretir. Bu nedenle grafik katmanını, kuralları ve eşikleri sahada kalibre edilmiş modüllerin üzerine kuruyoruz; yanlış alarm azaltma yazısında anlattığımız teknikler burada da temel koşuldur. Tersinden de fayda vardır: bağlamı olmayan, hiçbir zincire bağlanmayan ve sürekli aynı noktada tekrar eden alarmlar çoğu zaman kamera açısı ya da kural ayarı sorununa işaret eder.

Üretimde karşılığı

Aynı yöntem duruş analizinde çalışır: besleme gecikmesi → operatör bekleme → hat durması zinciri, üç ayrı metrik yerine tek bir neden olarak görünür. İyileştirme çalışması doğru yere odaklanır.

Üretimde grafiğe kamera olaylarının yanında makine sinyalleri de girebilir: PLC'den gelen duruş kodu, MES'teki iş emri değişimi, kalite istasyonundaki red kaydı. Olaylar REST API ve MQTT üzerinden yayınlandığı için bu sistemlerle aynı zaman ekseninde birleştirilebilir. Böylece “hat neden durdu” sorusunun cevabı, vardiya sonundaki toplantıda hafızadan değil, sıralı olay kaydından verilir.

Aynı mantık İSG tarafında da geçerlidir; bir örnek bölge ihlallerinden gelir. Bir pres çevresindeki ihlaller ayrı ayrı okunduğunda rastgele dağılmış gibi görünebilir; makine durumu grafiğe eklendiğinde ihlallerin belirli bir operasyon, örneğin kalıp değişimi sırasında yoğunlaştığı görülür. Bu durumda çözüm, operatörleri tek tek uyarmak değil, o operasyon için güvenli bir çalışma yöntemi ve gerekirse kuralın makine durumuna bağlanmasıdır.

Neden önemli?

Analitik olgunluk merdiveninde basamaklar şöyledir: ne oldu, neden oldu, ne olacak, ne yapmalı. Olay grafikleri ikinci basamağı otomatikleştirir — ve üçüncü basamağın temelini kurar.

Tekrarlayan zincirler bilindiğinde, zincirin ilk halkası göründüğünde sonrakilerin olasılığı da hesaplanabilir; bu, tahmine dayalı güvenlik modellerinin girdisidir. Dördüncü basamakta ise öneri üreten sistemler devreye girer: koridor tıkandığında sorumlu ekibe iş emri açmak gibi. Bu tür karar destek akışlarını fabrikada ajan tabanlı yapay zekâ yazısında tartıştık.

Nasıl başlanır?

Olay grafiği ayrı bir proje olarak değil, çalışan analitik modüllerinin üzerine eklenen bir katman olarak kurulur. Başlangıç için birkaç ay boyunca düzenli olay üreten, eşikleri kalibre edilmiş bir veri akışı gerekir. İlk adımda sahadaki bölgeler ve komşulukları tanımlanır, İSG ve üretim ekibiyle hangi olay tiplerinin birlikte okunacağı belirlenir. Grafik bireyleri değil olayları ve bölgeleri modeller; kişi kimliği tutulmaz, yüz tanıma kullanılmaz.

İlk birkaç haftada ortaya çıkan hipotezlerin bir kısmı ekip için sürpriz olmayacaktır; bu beklenen bir durumdur ve sistemin sahayı doğru okuduğunu gösterir. Değer, ekibin sezgiyle bildiği şeyleri ölçülebilir hâle getirmekte ve fark edilmeyen zincirleri görünür kılmaktadır. Hipotezlerin ne kadarının sahada doğrulandığı pilot süresince kaydedilir ve raporlanır. Doğrulanan her zincir için alınan önlem ve sonrasındaki olay sıklığı da aynı rapora eklenir; böylece yöntemin değeri, anlatılan örneklerle değil, sahanın kendi verisiyle görülür.

Sık sorulan sorular

Olay grafiği için ek kamera ya da donanım gerekir mi?

Genelde gerekmez. Olay grafiği, mevcut analitik modüllerinin ürettiği olay kayıtları üzerinde çalışan bir yazılım katmanıdır. Aynı edge sunucuda ya da tesis içindeki ayrı bir sunucuda çalıştırılabilir. Ek ihtiyaç çoğunlukla veri tarafındadır: olayların doğru zaman damgası ve bölge bilgisiyle kaydedilmesi, makine sinyalleri kullanılacaksa PLC veya MES bağlantısı.

Sistemin önerdiği kök neden yanlış çıkarsa ne olur?

Sistem kök nedeni kesin hüküm olarak değil, hipotez olarak sunar ve arkasındaki olay kliplerini gösterir. Ekip klipleri inceler, hipotezi onaylar ya da reddeder. Reddedilen hipotezler kayıt altına alınır ve benzer zincirlerin önceliği düşürülür. Karar her zaman sahayı bilen ekiptedir. Bu geri bildirim zamanla hipotez kalitesini iyileştirir.

Hangi sistemlerle entegre olur?

Kamera olaylarının yanında PLC/SCADA sinyalleri, MES iş emirleri ve kalite kayıtları aynı zaman ekseninde birleştirilebilir. Olaylar REST API ve MQTT üzerinden yayınlandığı için mevcut MES, ERP, VMS ve alarm altyapısına bağlanabilir. Hangi kaynakların ekleneceği, keşifte cevaplanmak istenen sorulara göre seçilir.

Olay grafiği kişileri izlemek için kullanılabilir mi?

Bizim kurgumuzda hayır. Grafik olayları, bölgeleri ve süreçleri modeller; kişi kimliği tutulmaz ve yüz tanıma kullanılmaz. Amaç kimin hata yaptığını bulmak değil, hangi koşulun tekrarlayan riski ürettiğini görmektir. Varsayılan kurulumda görüntü tesis içindeki edge sunucuda işlenir, olay klipleri tanımlı saklama süresi sonunda otomatik silinir.