Anlık OEE takibi için mühendislik rehberi

Fabrikaların çoğuna OEE (Toplam Ekipman Etkinliği) değerlerini sorduğunuzda size bir vardiya raporu, bir Excel tablosu ya da beyaz tahtadan okunmuş bir sayı verilir. Bu sayı yine de bir fikir verir, ama çoğu zaman gecikmeli raporlamayı, yuvarlanmış duruş kayıtlarını ve kısa duruşların eksik sayılmasını da içinde taşır.

Pek çok tesiste OEE, bir mühendislik aracına dönüşmeden önce bir raporlama göstergesi hâline gelir. Bu yazı tam olarak bu açığı ele alıyor.

Anlık OEE takibi formülü değiştirmez. Değişen şey, olayların ne kadar doğru yakalandığı, makine durumlarının ne kadar tutarlı tanımlandığı ve operasyonun kayıp örüntülerine ne kadar hızlı tepki verebildiğidir.

Bu rehberin odağı uygulama mimarisidir. OEE'nin makinenin hemen yanında nasıl hesaplanacağını ve makinenin kendi duruşlarının malzeme bekleme ya da çıkış tıkanıklığı gibi hattan kaynaklanan kayıplardan nasıl ayrılacağını anlatıyoruz. Sonuçların tek bir panoya hapsolmadan başka yerlerde de kullanılabilmesi için bir Unified Namespace (UNS) içine nasıl yayınlanacağını da gösteriyoruz.

• %85: Sık anılan, ama sektöre göre sınırları olan bir hedef değeri
• Elle kayıt yanılgısı: Kısa duruşlar çoğu zaman eksik raporlanır
• Sahada hesaplama: Gecikmesi düşük OEE kararları için en uygun yer

Sahada görülen performans iş yükünün niteliğine, düğüm kapasitesine ve kurulum tasarımına bağlıdır.

"Gerçek" OEE'yi oluşturan unsurlar

Kod yazmaya başlamadan önce yaklaşım üzerinde anlaşmak gerekir. Anlık OEE, raporlarda gördüğümüz OEE'den üç önemli noktada ayrılır:

1. Ayrıntı: Olayları dakika değil, milisaniye düzeyinde yakalar.
2. Bağlam: Teorik hızı doğru belirleyebilmek için o anda hangi ürünün üretildiğini (SKU bilgisi) bilir.
3. Otomasyon: Örneklemenin getirdiği sınırları azaltır. Hesabı doğrudan PLC'den yüksek sıklıkta okunan durumlar yürütür.

Altı büyük kayıp ve dijital karşılıkları

Sağlam bir OEE hesaplama motoru kurmak için TPM'nin klasik "Altı Büyük Kayıp" kategorilerini Edge Gateway'inizdeki dijital sinyallerle eşleştirmeniz gerekir.

OEE neden sahada hesaplanmalı?

Pek çok IIoT platformu ham sensör verisini buluta taşıyıp OEE'yi orada hesaplama hatasına düşer. Bu, yaklaşımın temelindeki bir kusurdur.

Düşük gecikme ve bağlantı kesintisine dayanıklılık için OEE'yi sahada hesaplamak genellikle en doğrusudur.

Neden mi?

1. Gecikme: Operatör hedefin gerisinde kaldığını hemen öğrenmelidir; buluttaki toplu bir işlemin 15 dakika sonra bitmesini bekleyemez.
2. Veri hacmi: Milisaniyelik her durum değişikliğini WAN üzerinden göndermek hem pahalı hem kırılgandır.
3. Çözünürlük: 200 ms'lik bir mikro duruşu yakalamak, buluttaki gecikmeli özetlemeyle değil, genellikle sahada işlemeyle mümkündür.

Hesaplama akışı

Proxus'ta bu tür bir mantık, sahadaki Edge Gateway'de çalışan bir C# fonksiyonudur. Fonksiyon Proxus SDK ile yazılır, merkez sunucuda derlenir ve oradan Edge Gateway'e dağıtılır.

Mikro duruşları yakalamak

Yatırımın asıl geri döndüğü yer burasıdır. Mikro duruş, genellikle 2-5 dakikadan kısa süren duruştur. Operatörler bunları neredeyse hiç kayda geçirmez; sıkışmayı giderir, makineyi yeniden başlatır ve devam eder.

Ama bir makine bir vardiyada 40 kez 30'ar saniye durursa toplamda yine 20 dakikalık üretim kaybedilmiş olur. Bu kayıplar resmî duruş sürecini başlatmak için fazla küçük, hat düzeyinde görmezden gelinemeyecek kadar da büyüktür.

Mikro duruşların etkisi: görünmeyen üretim kayıpları

Mikro duruş mantığını kurmak

Bağlantılar karmaşık olsa da hedef basittir:

1. Makine durum değişikliklerini yeterli çözünürlükte yakalayın.
2. Duruşun başladığı anın zaman damgasını işaretleyin.
3. Makine yeniden çalışmaya geçtiğinde duruşun süresini hesaplayın.
4. Duruşu tesisin belirlediği eşiğe göre sınıflandırın.
5. Sonucu hattın bağlamıyla birlikte yayınlayın; böylece vardiyalar, SKU'lar ve istasyonlar tutarlı biçimde karşılaştırılabilir.

Mantığı ister görsel bir araçla kurun ister betikle yazın, belirleyici olan sözdizimi değildir. Önemli olan sağlam bir durum modeli, net bir mikro duruş eşiği kuralı ve sonraki raporlarda yeniden kullanılabilecek bir konu yapısıdır.

Kayıp olayları UNS'e yayınlandıktan sonra ekipler, kısa duruşların nerede yoğunlaştığını gösteren ısı haritaları ve vardiya bazında trend görünümleri hazırlayabilir. Bu duruşlar çoğu zaman vardiya değişimlerinde, malzeme değişimlerinde, ürün geçişlerinde ya da makinenin belirli bölümlerinde toplanır.

Malzeme bekleme ve çıkış tıkanıklığında kayıp kime yazılır?

Duran bir makine çoğu zaman "arızalı" değildir. Sürekli çalışan bir üretim hattında her şeyi bağlam belirler.

• Malzeme bekleme (Starved): Makine çalışmaya hazırdır, ama önceki makineden malzeme gelmemiştir.
• Çıkış tıkanıklığı (Blocked): Makine sorunsuz çalışmaktadır, ama sonraki makine dolu ya da durmuş olduğu için konveyörde birikme olmuştur.

Bir makinenin OEE'sini malzeme beklediği ya da çıkışı tıkandığı için düşürürseniz operatörler tepki gösterir: "Dolum makinesinin durması benim suçum mu?" Bu soruda haklıdırlar.

Hat bütünlüğünü hesaba katmak

OEE mantığınızda iç duruşu (makinenin kendi arızası) dış duruştan (malzeme bekleme ya da çıkış tıkanıklığı) ayırmanız gerekir.

Uygulama ipucu: OEE hesaplanırken malzeme bekleme ve çıkış tıkanıklığı süreleri genellikle o makinenin Kullanılabilirlik hesabından çıkarılır ya da ayrı bir kalem olarak "Hat kayıpları" altında toplanır.

Performansta ideal çevrim süresi tuzağı

Performans bileşeni şöyle hesaplanır:

Performans = (Toplam adet × İdeal çevrim süresi) ÷ Çalışma süresi

En sık yapılan hata, ideal çevrim süresi olarak makinenin etiketindeki sabit hızı kullanmaktır.

• Senaryo: Makinenin etiketinde saatte 1.000 adet yazıyor.
• Gerçek: Küçük A ürününde makine gerçekten saatte 1.000 adet üretebiliyor. Büyük B ürününde ise fiziksel sınırlar nedeniyle en fazla 600 adet çıkarabiliyor.

B ürününü saatte 1.000 adet standardıyla hesaplarsanız Performans hiç kıpırdamadan %60'ta kalır. Hedef baştan ulaşılamaz göründüğü için ekiplerin bu göstergeye güveni de azalır.

Hedefi ürüne göre değiştirmek

İdeal çevrim süresini o anda üretilen SKU'ya göre dinamik olarak almanız gerekir.

1. İş emri bilgisi: Üretilen işin bilgisi Edge Gateway'e ulaşmalıdır. Proxus'ta MES ya da ERP tarafı bu bilgiyi Edge Gateway'in kendi MQTT sunucusuna yayınlayabilir (Proxus dışarıdaki MQTT sunucularına abone olmaz) ya da operatör bu bilgiyi hattın başında girebilir.
2. Eşleştirme tablosu: Fonksiyon, her SKU'nun ideal çevrim süresini merkez sunucudan gelen yapılandırmasında taşır: { "SKU_001": 0.5s, "SKU_002": 0.8s }.
3. Anında güncelleme: İş emri değiştiğinde formüldeki payda kendiliğinden güncellenir.

Böylece %100 Performans, "Bu ürün için fiziksel olarak mümkün olan en yüksek hızda çalışıyoruz" anlamına gelir.

Andon panolarıyla OEE'yi görünür kılmak

Topladığınız veriyi etkili biçimde göstermezseniz bir işe yaramaz. Andon panosu, sahaya asılan ve anında geri bildirim veren büyük bir TV ekranıdır.

Gösterimin psikolojisi

Ekranda yalnızca "OEE = %65" yazmayın; bu, sahadaki çalışanlar için soyut bir rakamdır. Bunun yerine "kaybedilen adedi" gösterin.

• "Bugün duruşlar yüzünden 350 şişe kaybettik."
• "Planın 15 dakika gerisindeyiz."

Bu tür göstergeler insanları harekete geçirir. Operatörler yüzdeleri değil, "şişeyi" ve "dakikayı" sezgiyle anlar.

Uygulama kontrol listesi

Kurmaya hazır mısınız? Proxus ile anlık OEE takibini devreye almak için kontrol listesi aşağıda.

Bu yaklaşım ne zaman uygun olmayabilir?

• Seyrek gelen telemetri, tamamen dağıtık bir mimarinin karmaşıklığına değmeyebilir.
• Küçük, tek hatlık tesisler işe daha basit mimarilerle başlamayı tercih edebilir.
• Eski sistemlerden gelen katı kısıtlar, geçişin aşama aşama yapılmasını gerektirebilir.
• Güvenlik açısından kritik kapalı çevrim kontrol, PLC ve Safety PLC katmanlarında kalmalıdır.

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

Sık sorulan sorular

Çoğu fabrika için gerçekçi bir OEE hedefi nedir?

Dünya standardı OEE'nin genellikle %85 olduğu söylenir (%90 kullanılabilirlik × %95 performans × %99,9 kalite). Ancak bu değer büyük ölçüde bağlama bağlıdır ve her sektöre doğrudan uygulanamaz. Bir içecek dolum hattı gerçekçi olarak %80'e ulaşabilirken, partiler hâlinde çalışan bir kimyasal reaktör, doğası gereği sık ürün değişimi nedeniyle %60'ın üstüne çıkmakta zorlanabilir. Asıl önemli olan mutlak değer değil, zaman içindeki iyileşme hızıdır.

Planlı duruşlar OEE hesabına dâhil edilmeli mi?

Hayır. Standart OEE yöntemi planlı duruşları (planlı bakım, molalar, üretim yapılmayan vardiyalar) paydanın dışında tutar. Bunları dâhil ederseniz farklı bir gösterge olan TEEP'i (Total Effective Equipment Performance) ölçmüş olursunuz. İkisini karıştırmak, tesisler arasında yanıltıcı karşılaştırmalara yol açar.

Parti üretiminde ve sürekli hatlarda OEE nasıl hesaplanır?

Parti (batch) üretiminde "ideal çevrim süresi" yerine "ideal parti süresini" kullanın. Performans = (Parti sayısı × İdeal parti süresi) / Çalışma süresi. Kalite de adet başına değil, parti başına ölçülür. Durum makinesi mantığı aynı kalır; yalnızca zaman çözünürlüğü saniyelerden dakikalara çıkar.

Elle tutulan kayıtlar OEE'nin doğruluğunu nasıl etkiler?

Elle tutulan kayıtlar doğası gereği örnekleme hatalarına ve yuvarlamaya açıktır. Operatörler sorunu çözmeye odaklanmışken mikro duruşları atlayabilir ya da zamanları ancak yaklaşık olarak yazabilir. Hesabı doğrudan makinenin durumu yürüttüğünde bu ölçüm sınırları azalır. Otomatik OEE'nin başlangıçta elle hesaplanan OEE'den düşük çıkması çok yaygındır; çünkü dijital sistem, daha önce görmezden gelinen ya da yuvarlanıp kaybolan kısa kayıpları ortaya çıkarır.

OEE ile makine duruş maliyeti arasında nasıl bir ilişki var?

OEE; kullanılabilirlik, performans ve kalite açısından neyin kaybedildiğini ölçer. Gerçek duruş maliyeti (True Downtime Cost, TDC) ise bu kayıpların parasal karşılığını ortaya koyar. İkisi birbirini tamamlar: OEE kaybın nerede biriktiğini gösterir, TDC ise hangi kayıp için önce operasyonel ya da yatırım harcaması yapılması gerektiğine karar vermeye yardım eder.

Sonuç

OEE bir karne değil, bir teşhis aracıdır. Amaç verimsizlikleri örten "yüksek bir puan" tutturmak değil, prosesin içinde gizlenmiş kayıp kapasiteyi bulup çıkarmaktır.

Gecikmeli, elle hazırlanan raporlardan sahada hesaplanan anlık bir OEE mimarisine geçen ekipler mikro duruşları daha çabuk görür. Bu ekipler her SKU için daha inandırıcı performans hedefleri koyar ve makinenin kendi kayıplarını hattan kaynaklanan kayıplardan daha net ayırır.

Bu, OEE'yi her derde deva yapmaz. Ama onu mühendislerin, vardiya amirlerinin ve iyileştirme ekiplerinin gerçekten kullanabileceği, daha güvenilir bir operasyon göstergesine dönüştürür.

Kaynaklar

1. OEE.com - Calculating OEE - Tercih edilen OEE formülü ve bileşenlerinin tanımları için uygulamalı başvuru kaynağı. OEE Calculation
2. ISO 22400-2 - OEE ve alt bileşenleri dâhil, üretim operasyonları yönetimine ait temel performans göstergeleri. ISO 22400
3. Seiichi Nakajima, "Introduction to TPM" (1988) - Toplam Verimli Bakım (TPM) kapsamında OEE'nin ve Altı Büyük Kayıp yaklaşımının ilk tanımı.
4. ISA-95 / IEC 62264 - Kurumsal sistemlerle kontrol sistemlerinin entegrasyonuna dair standart; OEE metriklerini UNS'e yayınlarken kullanılan veri ağacı tasarımıyla doğrudan ilgilidir.
5. Hansen, Robert C., "Overall Equipment Effectiveness" (2001) - Farklı üretim ortamlarında OEE uygulamasına dair pratik bir rehber.

Gerçek OEE'nizi hesaplamaya hazır mısınız? Bu mantığın nasıl çalıştığını görmek için Proxus uç mimarisini inceleyin, makine ve OEE görünürlüğü ile beslediği panolar ve raporlar hakkında okuyun ya da hatlarınızdan biri için OEE pilotunu birlikte planlayalım.