Pres hattında anomali tespiti, olağandışı bir görüntü veya proses davranışını fark etmek için tasarlanabilir. Fakat “normalden farklı” sonucu, kendi başına “hatalı parça”, “arıza” veya “hattı durdur” kararı değildir. Projenin asıl işi bu farkın işletmede hangi karara karşılık geldiğini tanımlamaktır.
Pres hattında canlı sonuç üreten anomali tespit sistemleri geliştirdim. Burada belirli bir hattın kapasitesini, hangi tesiste çalıştığını veya kullanılan ticari bileşenleri paylaşmıyorum. Yazının kalanında benzer bir ihtiyacın nasıl projelendirilebileceğine ilişkin genel yaklaşımı anlatıyorum; her adımın geçmiş projede birebir uygulandığını iddia etmiyorum.
Önce “neyin anomalisi?” sorusu
İki işletme aynı ifadeyi kullanırken farklı şeyler istiyor olabilir. Birinde çıkan parçanın görünümü, diğerinde ölçülen proses davranışı incelenmek istenebilir. Veri kaynağı ve kabul ölçütleri bu ayrıma göre değişir.
Bu yüzden başlangıç tanımı açık olmalı:
- İzlenen nesne veya süreç nedir?
- Normal koşul hangi ürün ve çalışma bağlamı için geçerlidir?
- Uyarı hangi kararı destekleyecek?
- Hangi değişiklik beklenen üretim farklılığı, hangisi araştırılacak durumdur?
Yeni bir ürünün görüntüsünün farklı olması, otomatik olarak üretim sorunu demek değildir. Normalin tanımı işletme bağlamından koparılırsa model çıktısının anlamı da belirsizleşir.
Görsel kontrol ve proses izlemeyi birbirine karıştırmamak
Görüntü temelli bir yapı için görüntü edinimi ve parçanın sunuluşu önemlidir. Proses verisiyle çalışan yapıda ise mevcut ölçüm kaynağı, zaman eşleştirmesi ve sinyalin anlamı incelenmelidir. Hangi verinin kullanıldığı bilinmeden belirli bir kamera, sensör veya model öneremeyiz.
Endüstriyel görsel anomali tespitinin araştırma örneklerinden biri MVTec AD veri setidir. Bu veri seti yöntemleri karşılaştırmaya yardımcı olur; bir pres hattında aynı başarının elde edileceğini veya verisinin sizin hattınızı temsil ettiğini kanıtlamaz. Kendi geliştirdiğim projede bu veri setini kullandığımı da söylemiyorum. MVTec AD
Veri toplama yaklaşımının kurumsal tarafı için şirket verisini yapay zekâya hazırlama yazısını okuyabilirsiniz.
Canlı sonuç doğru parçaya bağlanmalı
Bir modelin ekranda sonuç üretmesi yeterli değil. Sonuç hangi parçaya veya proses olayına ait? Operatör aynı sonucu hangi kayıtta görecek? Veri kaynağı gecikirse veya yeni bir olay gelirse önceki sonuç yanlış yere iliştirilebilir mi?
Genel bir tasarım akışı şöyle kurulabilir:
Olay/parça kaydı → veri edinimi → bağlamın belirlenmesi → analiz → sonuç eşleştirmesi → insan veya uygulama tarafından değerlendirme.
Bu, geçmiş bir tesisin mimarisi değil, tartışmaya açılabilecek temsili bir akıştır. Bazı sistemlerde parça kimliği bulunmayabilir; bu durumda hangi eşleştirme yapılabildiği ve sınırları ayrıca yazılmalıdır.
“Gerçek zamanlı” için tek bir süre yok
Canlı sonucun ne kadar hızlı olması gerektiği, işletmenin karar penceresine bağlıdır. Yalnızca modelin çalışma süresini ölçmek bu pencereyi anlatmaz. Verinin alınması, aktarılması, işlenmesi, sonucun kaydedilmesi ve görünür hale gelmesi birlikte değerlendirilir.
Başlangıçta sorulabilecek soru şudur: “Sonuç en geç ne zaman kullanılabilir olmalı ve bu süre aşılırsa ne yapılmalı?” Süre aşımının sessizce normal sonuç gibi gösterilmemesi gerekir. Veri gelmemesi de “anomali yok” sonucuyla aynı şey değildir.
Yanlış alarm operatörün iş yüküdür
Bir anomali skoru için eşik seçmek teknik olduğu kadar operasyonel bir karardır. Kaçırılan önemli olaylar ile gereksiz incelemeler ayrı değerlendirilmelidir. Her uyarıda uzman incelemesi gerekiyorsa, o incelemenin iş yükü pilotun ölçümlerine dahil edilmelidir.
Önerilen pilot kayıtları:
| Kayıt | Yanıtladığı soru |
|---|---|
| Uyarı ve uzman kararı | Hangi uyarılar gerçekten araştırmaya değerdi? |
| Kaçan örnekler | Referans kontrolde görülen neyi sistem kaçırdı? |
| Gecikme ve sonuç yokluğu | Karar zamanında kullanılabilir miydi? |
| Ürün/koşul bağlamı | Sonuç hangi koşulda değişti? |
| İnsan inceleme süresi | Kontrol yükü nasıl etkilendi? |
Bu alanların her biri ölçülebilir olmadan genel bir başarı yüzdesi açıklamak, projenin işletmeye etkisini gizleyebilir. KPI ve başarı ölçümü yazısında bu ayrımı genişletiyorum.
Pres hattı pilotu için karar ve hata durumları kartı
Bir pilotta yalnızca uyarı çıktısını değil, uyarının kullanılacağı koşulları da yazılı hale getirin. Bu genel şablon, bir tesisin gerçek devreye alma kaydı değildir.
| Durum | Pilot öncesinde verilecek karar |
|---|---|
| Normal kapsam | Hangi ürün, çalışma koşulu ve veri kaynağı değerlendirilecek? |
| Uyarı geldi | Kim inceleyecek; uzman kararı hangi kayda bağlanacak? |
| Veri gelmedi | Sonuç yokluğu nasıl gösterilecek; mevcut kontrol nasıl devam edecek? |
| Sonuç gecikti | Karar penceresi aşıldığında sonuç nasıl işaretlenecek? |
| Eşleşme bulunamadı | Hangi kayıt araştırılacak; doğrulanmamış sonuç nasıl ayrılacak? |
| Ürün/koşul değişti | Yeniden değerlendirmeyi kim başlatacak? |
Pilotun değerlendirme dönemi, kaçırılan olayların referans kontrolü ve yanlış uyarıların inceleme yükü baştan belirlenmeli. Uyarı eşiğini bir arıza veya otomatik durdurma eşiği gibi sunmayın. Ölçüm tanımlarını KPI ve başarı ölçümü kartıyla birlikte hazırlayabilirsiniz.
Asıl ihtiyacınız açıkça tanımlanmış bir kusurun kabul/red kontrolüyse görüntü işleme ile kalite kontrol rehberi daha uygun bir başlangıç olabilir. İstasyon düzeyinde parça kontrolü için krank muayene akışını ayrıca ele alıyorum.
Anomali tespiti, arıza tahmini değildir
Olağandışı bir durumun saptanması, ekipmanın ne zaman arızalanacağını bildiğimiz anlamına gelmez. Kestirimci bakım için ilgili bakım/arıza kayıtlarının ve değerlendirme tasarımının ayrıca ele alınması gerekir. Görsel fark, proses sapması ve gelecekteki arıza aynı hedef gibi sunulmamalıdır.
İlk aşamada uygun bir yaklaşım, mevcut kontrolü değiştirmeden sonuçları karşılaştırmak olabilir. Otomatik üretim aksiyonu ancak ilgili kontrol sorumluları, güvenlik gereksinimleri ve hata durumları ayrıca değerlendirilerek ele alınmalıdır.
Sistem devreye girdikten sonra iş bitmez
Ürün ve çalışma koşulları değiştiğinde sistemin yeniden değerlendirilmesi gerekebilir. “Hangi değişiklikte kontrol yapacağız, kim karar verecek, önceki sonuçlar nasıl karşılaştırılacak?” soruları canlıya geçiş planında yer almalı.
NIST AI RMF üretimde davranışın izlenmesini ele alır. Bu genel risk yönetimi çerçevesini, bir pres hattına özel donanım veya güvenlik uygunluğu belgesi yerine kullanmamalıyız. NIST AI RMF Core
Pres hattında anomali tespitini değerlendiren bir işletme için başlangıç; bir model seçmek değil, izlenecek durumu ve desteklenecek kararı netleştirmektir. Üretimde diğer kullanım alanlarına üretim ve operasyon süreçlerinde yapay zekâ rehberinden ulaşabilir, kendi ihtiyacınızı benimle konuşabilirsiniz.