Önce şu soruyu cevaplayın: kaç arızanız var
Kestirimci bakım (predictive maintenance) talebi genelde şu cümleyle geliyor: “Rulman arızasını önceden görmek istiyoruz, iki yıllık veri var.” Sorulacak ilk soru modelin türü değil, o iki yılda kaç arıza yaşandığı.
Cevap “üç” ise model kurulmaz. Bu bir yetenek sorunu değil, sayı sorunu. Denetimli öğrenme (supervised learning) bir olayı öğrenmek için o olayın çok sayıda örneğini görmek zorunda; üç örnekle eğitilen bir sınıflandırıcı arızanın fiziğini değil o üç olayın kendine özgü gürültüsünü öğrenir. Doğrulama için ayıracak dördüncü örnek de yoktur — yani modelin çalışıp çalışmadığını ölçmenin yolu bile kapalıdır.
İyi bakım yapan tesisin cezalandırıldığı bir paradoks: kritik ekipman hiç arızalanmadığı için etiketli olumsuz örnek de yok. Kalan üç yol:
- Anomali tespiti. Yalnız “normal” veriden sağlık modeli kurulur, sapma raporlanır. Arıza etiketi gerekmez ama çıktı “arıza gelecek” değil, “bu davranış öğrendiğime benzemiyor” olur — operatöre de öyle sunulur.
- Filo verisi. Aynı tip ekipmanın onlarca kopyası varsa arıza sayısı tesis değil filo düzeyinde toplanır. Tek makineli hatta bu yol yok.
- Fiziksel model. Titreşim spektrumunda rulman geçiş frekansları hesaplanır; bunun için veri değil geometri ve devir bilgisi gerekir.
Yol hangisi olursa olsun aşağıdaki yedi maddenin cevabı hazır olmalı — ilk sensör seçilirken, veri toplandıktan sonra değil.
1. Etiket sözlüğü ve birim tutarlılığı
Veri kümesindeki her kolonun neyi, hangi birimde, hangi noktadan ölçtüğü yazılı olmalı.
TT_0421 etiketinin sıcaklık olduğunu tahmin edebilirsiniz; Celsius mu Fahrenheit mı, ham
mı filtrelenmiş mi olduğunu tahmin edemezsiniz.
En sık iki tuzak: aynı büyüklüğün iki noktada iki farklı birimle kaydedilmesi (PLC’de bar, raporlamada kPa) ve ölçek dönüşümünün (scaling) bazı etiketlerde uygulanıp bazılarında uygulanmaması. Model bunu hata görmez — iki katı büyüklükteki değişkeni daha “önemli” sanıp ağırlığı ona verir. Etiket sözlüğü veri toplama ve analiz tarafında bir kez doğru kurulduğunda üstüne gelen her katman ondan besleniyor.
2. Örnekleme aralığı ve ölü bant
Tahmin edilecek olayın süresi örnekleme aralığını belirler. Saatler içinde gelişen rulman aşınması için 1 saniyelik örnekleme fazlasıyla yeterli. Kavitasyon, elektriksel ark ve darbe tipi mekanik olaylar ise milisaniye ölçeğindedir; saniyede bir okunan kayıt bunları hiç görmez.
Daha sinsi olan ölü bant (deadband). Çoğu SCADA ve tarihçe (historian) yazılımı bandı aşmayan değişimi kaydetmez; disk alanı için makul, süreç izleme için sorunsuz bir karardır. Ama sonuçta elinizde eşit aralıklı bir zaman serisi değil olay tabanlı bir kayıt olur. Bunu düz tabloya çevirmek için yapılan ileri doldurma (forward fill), sinyalin hiç oynamadığı izlenimini verir ve varyans temelli her öznitelik (feature) çöker.
Karar ölçütü: eğitim arşivi, en azından modelin kullandığı etiketlerde ölü bandı kapatılmış ayrı bir akış olmalı. Bu, mevcut tarihçenin yanına ikinci bir toplama hattı kurmak demek; maliyeti önceden bilinsin.
3. Saat senkronizasyonu
Veri birden fazla kaynaktan (PLC, enerji analizörü, titreşim ölçer, MES) birleştiriliyorsa hepsinin saati ortak bir kaynağa bağlı olmalı. NTP yeterli; alt milisaniye gerektiren ölçümde PTP (IEEE 1588) gerekir.
Senkronizasyon yoksa olan şudur: sebep sonucun arkasına düşer. 40 saniye ileri giden bir cihazın alarmı, onu tetikleyen basınç düşüşünden önce görünür; model bu ilişkiyi olduğu gibi öğrenir ve alarmı basıncın öncüsü sanar. Hata veriye bakınca fark edilmez, çünkü iki seri de kendi içinde tutarlıdır.
Önlem: her kaynağın saat sapması periyodik ölçülüp kaydedilir. Zaman damgasının protokoller arası taşınması haberleşme sistemleri tarafında ayrı bir mühendislik işi — OPC UA gibi protokollerin değerle birlikte kaynak zaman damgası ve kalite bayrağı taşıması tam bu yüzden değerli.
4. Bakım kayıtlarının makine verisiyle eşleştirilebilirliği
Makine verisi genelde temizdir; sorun etiket tarafında. “Arıza şurada oldu” bilgisi çoğu tesiste serbest metin bir bakım defterinden gelir:
14.03 — motor ısındı, fan bakıldı, tamam
Bu satırdan model eğitilemez. Saat yok (hangi vardiya?), ekipman kimliği yok (hangi motor?), arıza tipi sınıflandırılmamış, “tamam” bir tamir mi gözlem mi belirsiz. Aynı arıza üç teknisyende “rulman sesi”, “yatak gürültüsü” ve “anormal ses” olarak yazıldıysa model için üç ayrı sınıftır.
Yapılacak iş defteri geriye dönük düzeltmek değil, ileriye dönük kapalı listeli bir arıza kaydı kurmak: tarih-saat, ekipman kodu, sabit listeden arıza tipi, duruş süresi, değişen parça. Serbest metin alanı kalabilir ama sınıflandırma ondan bağımsız olmalı. Bu yapılmadan başlanan projede etiketleme işi genelde toplam emeğin yarısını yer.
5. Çalışma rejimi bilgisi olmadan anomali tespiti
Sahada güveni en hızlı bitiren hata. Ürün A’dan B’ye geçildiğinde makinenin akım profili, sıcaklığı ve titreşim imzası değişir. Rejimden habersiz bir anomali modeli bunu arıza sanar ve her ürün değişiminin ilk saatinde alarm yağdırır. Sonuç teknik değil sosyal: bakım ekibi ikinci haftada modele bakmayı bırakır.
Önlem, girdiye bağlam (context) eklemek: aktif tarif (recipe) numarası, hat hızı, hammadde partisi, boşta/yüklü durumu, ısınma fazı bayrağı. Rejim sayısı azsa her rejime ayrı model kurmak tek büyük modelden daha sağlam çalışır. Bu bilgilerin çoğu PLC’de zaten var; sadece veri akışına eklenmemiş.
6. Kavram kayması ve yeniden eğitim
Üretim hattı sabit değil: rulman değişir, valf yenilenir, tedarikçi değişir, mevsim geçer. Modelin öğrendiği “normal” bugünün normalinden ayrışır — kavram kayması (concept drift). Belirtisi tanıdık: ilk ay iyi çalışan model üçüncü ayda yanlış alarm üretmeye başlar.
Bu yüzden bir ML kurulumu bir teslim değil bir bakım kalemidir. Devreye alma paketinde üç şey olmalı: girdi dağılımını izleyip kaymayı haber veren bir kontrol, yeniden eğitim için saklanan veri ve yazılı prosedür, her tahminin hangi model sürümüyle üretildiğini gösteren kayıt. Üçüncüsü olmadan geçmiş bir yanlış alarmın sebebi hiç bulunamaz.
7. Çıktı kime ne söylüyor
Model bir sayı üretir; o sayının eyleme dönüşmesi ayrı bir tasarım işi. İki temel seçenek:
Danışman mod. Çıktı operatöre veya bakım planlayıcısına öneri olarak gider, karar insanda kalır. Yanlış alarmın maliyeti bir kontrol turudur. Neredeyse her ilk kurulum burada başlamalı.
Kapalı çevrim. Çıktı doğrudan aksiyona bağlanır: hız düşürülür, hat durdurulur, set noktası değiştirilir. Eşik çok daha yüksek, çünkü artık istatistiksel bir tahmin proses kontrolüne müdahale ediyor. Kural net: güvenlik işlevleri modele bağlanmaz. Acil durdurma, koruma kapağı kilitlemesi, aşırı basınç ve sıcaklık koruması donanımsal güvenlik zinciriyle güvenlik PLC’sinde kalır; model katmanı bunları yalnız okur. Bir ML çıkışının olasılıksal doğası, güvenlik bütünlük seviyesi (SIL) gerektiren bir işlevin yerini alamaz.
Bazen doğru cevap model değil, eşiktir
Dürüst bölüm burası. Problem tek bir fiziksel büyüklükle açıklanabiliyorsa model gereksizdir ve genelde daha kötüdür.
Filtre tıkanması fark basıncıyla açıklanıyorsa çözüm bir eşik ve bir gecikme zamanıdır; motor aşırı yüklenmesi akımda görünüyorsa çözüm akım izlemedir. Bu kurallar şeffaftır, bakım ekibi neden tetiklendiğini bilir, doğrulaması bir öğleden sonra sürer ve on yıl bakım istemez. Aynı işi yapan model ise veri hattı, sürüm yönetimi ve yeniden eğitim yükü getirir.
Model, tek değişkenin yetmediği yerde kazanır: birkaç sinyalin birlikte hareketi anlam taşıyorsa, ilişki doğrusal değilse, ya da eşik çalışma rejimine göre değişiyorsa.
| Kontrol maddesi | Karşılanması gereken minimum | Karşılanmazsa sonuç |
|---|---|---|
| Etiketli arıza sayısı | Sınıf başına onlarca örnek, doğrulama için ayrı olaylar | Denetimli model kurulamaz |
| Etiket sözlüğü | Her kolonun anlamı, birimi, ölçüm noktası yazılı | Birim karışması ağırlıkları bozar |
| Örnekleme aralığı | Olay süresinin en çok onda biri | Olay hiç görünmez |
| Ölü bant | Model etiketlerinde kapalı | İleri doldurma yapay durağanlık üretir |
| Saat senkronizasyonu | Tüm kaynaklar NTP, hassas ölçümde PTP | Nedensellik ters öğrenilir |
| Bakım kaydı | Kapalı listeli arıza tipi, zaman, ekipman kodu | Etiketleme emeği projeyi ikiye katlar |
| Rejim bağlamı | Tarif, hız, yük durumu girdide | Ürün değişimi arıza sanılır |
| Yeniden eğitim planı | Kayma izleme, saklanan veri, sürüm kaydı | Model üçüncü ayda sessizce bozulur |
Yarın ne yapabilirsiniz
Model seçmeye gerek yok; iki saatlik bir iş var.
- Hedef ekipmanda son 24 ayın arıza sayısını sayın. Sayı tek haneliyse denetimli öğrenme masadan kalkar, konuşma anomali tespitine döner.
- Model için düşünülen etiketleri listeleyin; her biri için birim, ölçek dönüşümü ve ölü bant ayarını tarihçeden okuyun.
- Bakım defterinin son on kaydını açın ve sorun: bu satırı makine verisindeki bir zaman aralığıyla eşleştirebilir miyim? Cevap “hayır” ise ilk iş kayıt formunu düzeltmektir.
Bu üç adım, projenin uygulanabilir olup olmadığını tek satır kod yazmadan gösterir. Aynı hazırlık yapay zeka ve makine öğrenmesi tarafında ilk oturumda yaptığımız iş; çünkü verisi hazır olmayan bir modelin sonucu en iyi hâlde kimsenin bakmadığı bir gösterge tablosu oluyor.