Gerçek Zamanlı OEE Hesaplama Rehberi

Bir fabrikada OEE (Toplam Ekipman Etkinliği) değeri sorulduğunda çoğu zaman vardiya raporu, bir beyaz tahta veya Excel dosyası gösterilir. Bu sayı yine de işe yarayabilir; ancak gecikmeli raporlama, yuvarlanmış duruş kayıtları ve kaçırılan kısa stoplar nedeniyle üretim gerçeğinin tamamını yansıtmayabilir.

Birçok tesiste OEE önce raporlama KPI’ına, daha sonra mühendislik aracına dönüşür. Bu yazının amacı, bu sırayı tersine çevirmektir.

Gerçek zamanlı OEE, formülü değiştirmez. Değişen şey; olay yakalamanın çözünürlüğü, durum modelinin tutarlılığı ve operasyon ekibinin kayıplara ne kadar hızlı tepki verebildiğidir.

Bu rehber, uygulama mimarisine odaklanır: OEE’yi makineye yakın noktada nasıl hesaplayacağınızı, Besleme Yok (Starved) ve Çıkış Tıkalı (Blocked) gibi hat bağlamı kayıplarını iç arızalardan nasıl ayıracağınızı ve sonucu Birleşik İsim Alanı (UNS) üzerinden tekrar kullanılabilir bir operasyon verisine nasıl dönüştüreceğinizi inceler.

Sonuçlar yük profiline, donanım kapasitesine ve dağıtım topolojisine bağlıdır.

"Gerçek" OEE'nin Doğası

Bir satır bile kod yazmadan önce felsefede anlaşmamız gerekiyor. Gerçek zamanlı OEE, kağıt üzerindeki OEE'den üç temel noktada ayrılır:

1. Çözünürlük: Olayları dakikalarla değil, milisaniyeler bazında yakalar.
2. Bağlam: Doğru teorik hızı belirlemek için o an makinede hangi ürünün (SKU) çalıştığını bilir.
3. Otonomi (Automaticity): Manuel örnekleme kısıtlamalarını azaltır. Hesaplamalar, doğrudan PLC'nin yüksek frekanslı durum verileri (tag) ile otonom olarak gerçekleştirilir.

Dijital Haritalama: Altı Büyük Kayıp

Sağlam bir OEE motoru kurmak için TPM'in klasik "Altı Büyük Kayıp" (Six Big Losses) kavramını Proxus Edge Ağ Geçidi üzerindeki dijital sinyallerle eşleştirmeniz gerekir.

OEE Neden Uçta Hesaplanmalı?

Birçok IIoT platformu, sahadaki tüm ham sensör verisini saniyede bir buluta gönderip, OEE hesaplamasını orada yapmak gibi ağır bir mimari hata yapar.

Düşük gecikme ve çevrim dışı dayanıklılık gerektiğinde, OEE hesaplaması çoğu zaman sahada (Edge'de) daha uygun olur.

Neden mi?

1. Gecikme: Bir operatör veya formen hedefin gerisinde kaldığını 15 dakika sonra bulut raporları hazırlandığında değil, o "an" bilmesi gerekir.
2. Veri Hacmi: Her milisaniyelik durum değişimini internet üzerinden göndermek yavaş, pahalı ve kopmalara karşı dayanıksızdır.
3. Mikro Çözünürlük: Saniyenin onda biri kadar süren bir mikro duruşu kaçırmamak için hesaplamanın yerel olarak yapılması çoğu durumda daha güvenilir sonuç verir.

OEE Mantık Akışı (Logic Flow)

Proxus mimarisinde OEE hesaplama mantığı kurduğunu Docker konteynerinin içinde, yani direkt fabrika hattındaki Edge Gateway üzerinde çalışır.

Mikro Duruşları Yakalamak

Mikro duruşlar çoğu tesiste sistematik kayıp kaynaklarından biridir. Sensör kirlenir, ürün sıkışır, operatör kısa bir düzeltme yapar ve hat yeniden çalışır. Bu olayların her biri küçük görünür; ancak vardiya sonunda toplam kayıp anlamlı seviyeye ulaşabilir.

Mikro Duruş Mantığını Nasıl Kurmalısınız?

Mühendislik hedefi nettir:

1. makine durum değişimlerini yeterli çözünürlükte yakalamak
2. duruş başladığında zaman damgasını işaretlemek
3. makine yeniden çalıştığında duruş süresini hesaplamak
4. tesisin tanımladığı eşiklere göre mikro duruş ve normal duruş ayrımı yapmak
5. sonucu vardiya, SKU ve hat bağlamıyla birlikte yayınlamak

Bu mantık görsel kural veya script ile kurulabilir; kritik olan söz dizimi değil, durum modelinin tutarlı olması ve mikro duruş eşiğinin operasyon tarafından açıkça tanımlanmış olmasıdır.

Mikro duruş olayları UNS üzerine yayınlandığında, ekipler hangi saatlerde, hangi SKU’larda veya hangi makine segmentlerinde kümelendiğini çok daha net görebilir.

Besleme Yok mu, Çıkış mı Tıkalı? Atıf Problemi

Bir sürekli akış (continuous process) hattında, makinenin çalışmıyor olması "bozuk" olduğu anlamına gelmez.

• Besleme Yok (Starved): Makine çalışmaya hazır, motor devrede, operatör bekliyor; ancak bir önceki makine parça göndermediği için hat boş bekliyor.
• Çıkış Tıkalı (Blocked): Makine düzgün çalışıyor, ürün işliyor; ancak hemen sonrasındaki konveyör full dolduğu (veya sonraki makine arızalandığı) için mekanik sensörler hattı güvenliğe alıp bu makineyi de durduruyor.

Kritik Hata: Eğer Çıkış Tıkalı veya Besleme Yok nedeniyle duran makinenin Kullanılabilirlik (Availability) çarpanından puan düşerseniz, operatörleriniz isyan eder. "Şişeleme makinesi durduysa benim yüzümden değil ki!" derler. Ve haklıdırlar.

Hat Entegrasyonu ve Mantığı

Lokal PLC'yi dinlerken çoğu durumda makinenin dahili donanım arızası (Internal Downtime) ile dış faktörlü duruşların (External Downtime) birbirinden ayrılması gerekir.

Öneri: OEE hesaplarken "Starved" ve "Blocked" süreleri o makinenin şahsi OEE analizine negatif yansıtılmamalıdır. Bunun yerine bunlar sistemde farklı bir kategori olan "Line Losses" (Hat Kaybı / Senkronizasyon Kaybı) olarak loglanmalıdır.

Performans: Sabit Devir Tuzağından Kurtulmak

Performans (Performance) çarpanının bilinen formülü şöyledir:

Performans = (Toplam Üretilen Parça × İdeal Çevrim Süresi) ÷ Çalışma Süresi

Sahada en sık yapılan hata; İdeal Çevrim Süresi (Ideal Cycle Time) kısmına makinenin üretici kataloğundaki maksimum hızını tek bir sabit sayı olarak gömmektir.

• Senaryo: Katalogda makine hızı "1000 Parça / Saat" yazar.
• Gerçeklik: Makine fizik kuralları gereği (A) Tipi Küçük ürün için 1000 hıza ulaşabilir. Ama daha ağır, kompleks (B) Tipi ürün için o makinenin ulaşabileceği en güvenli ve stabil tepe hız zaten 600 adettir.

Eğer (B) Tipi ürünü imal ederken sisteme sabit "1000" ideal hedefini dayatan bir OEE altyapınız varsa; Performans çarpanı %60-65 seviyesine çakılı kalır. Bu durum, operatörlerin metriklere olan güvenini sarsabilir, çünkü hedef yapısal olarak ulaşılmaz görünmektedir.

Dinamik Hedef Takibi

İdeal Çevrim Süresi, genellikle sistemde "Hardcoded" (sabit) kalmamalıdır; o an hatta hangi ürün varsa ona göre dinamik güncellenmelidir.

1. ERP / MES Verisi Çekilir: Proxus ERP entegrasyonundan, o an çalışılan iş emrini (Current_Job_Order) UNS üzerine indirir.
2. Reçete Tablosu Dinlenir: Edge sunucudaki SQLite veya In-Memory veritabanı taranır: { "SKU_001": 0.5s, "SKU_002": 0.8s }.
3. Anlık Değişim: Ürün türü veya reçete değiştiği milisaniye; Edge Gateway de OEE hesaplayan formülün paydasını günceller.

Böylece Performans'ın %100 çıkması şu anlama gelir: "Şu an üretilen spesifik A ürünü için fiziksel olarak ulaşılabilecek en yüksek optimum hızı zaten yakalıyoruz." Operatörün de, mühendisin de güvendiği metrikler bu şekilde oluşturulur.

OEE'yi Görünür Kılmak: Andon Panoları

Dünyanın en kompleks ve algoritmik verilerini topluyor olsanız bile; bunu fabrika zeminiyle doğru bir formatta paylaşmazsanız ROI alamazsınız.

Görselleştirmenin Psikolojisi

Formenden "OEE %65 çıktı" gibi abstrakt bir çıkarım yapmasını beklemeyin. İnsan beyni oranları değil; kayıp olan hacmi ve süreyi anlar. Ekranda çok net bir şekilde "Kayıp Hacim" veya "Kayıp Zaman" gösterilmelidir.

• "Bugün plansız duruşlar yüzünden 350 şişe eksik ürettik."
• "Hedefin 15 dakika (70 palet) gerisindeyiz."

Bu metrikler doğrudan insan aksiyonunu tetikler. Yüzdeler (Puan) değil, miktar ve zaman kavramı operatörlerde eyleme geçme algısı yaratır.

Ne zaman uygun olmayabilir?

• Düşük frekanslı telemetride daha basit yaklaşımlar yeterli olabilir.
• Tek hatlı küçük tesislerde tam dağıtık mimari maliyet-etkin olmayabilir.
• Katı legacy kısıtları olan ortamlarda kademeli geçiş gerekebilir.
• Emniyet-kritik kapalı çevrim kontrol, PLC/Safety PLC katmanında kalmalıdır.

Bu davranış, topoloji ve yük özelliklerine göre değişebilir.

Sık Sorulan Sorular

Gerçekçi bir OEE hedefi fabrikalar için ne olmalıdır?

Dünya standartlarında OEE genellikle %85 (Kullanılabilirlik %90 × Performans %95 × Kalite %99,9) olarak referans verilir. Ancak bu kriter bağlama çok duyarlıdır ve her sektöre doğrudan uygulanamaz. Bir içecek dolum hattı %80'e ulaşabilirken, bir kimyasal parti reaktörü set değişimleri nedeniyle %60'ın üzerine çıkmakta zorlanabilir. Net sayıdan çok zaman içindeki iyileşme hızı önemlidir.

Planlı duruşları OEE hesabına dahil etmeli miyim?

Hayır. Standart OEE metodolojisi planlı duruşları (bakım, mola, üretim olmayan vardiyalar) paydadan çıkarır. Dahil ederseniz TEEP (Toplam Efektif Ekipman Performansı) ölçüyorsunuz demektir - bu farklı bir KPI'dır. İkisini karıştırmak tesisler arası yanıltıcı karşılaştırmalara yol açar.

Manuel veri girişi OEE doğruluğunu nasıl etkiler?

Manuel loglama doğası gereği yuvarlama ve örnekleme sınırlarına takılır. Mikro duruşlar kaçabilir veya olay zamanları yaklaşık girilebilir. Makinenin dijital durumu hesaplamayı doğrudan yönettiğinde bu sınırlamalar azalır. Bu yüzden otomatik OEE, ilk kurulumda manuel OEE’den daha düşük görünebilir; çoğu zaman sebep, sistemin daha önce görünmeyen kısa kayıpları ortaya çıkarmasıdır.

OEE, makine arıza maliyetiyle nasıl ilişkilidir?

OEE hangi kayıp deseninin oluştuğunu gösterir; Gerçek Duruş Maliyeti (TDC) ise bu kaybın finansal karşılığını hesaplamaya yardımcı olur. İkisi birlikte kullanıldığında, hangi ekipman veya kayıp türünün önce ele alınması gerektiği daha net önceliklenir.

Parti (batch) prosesler için OEE nasıl hesaplanır?

Parti proseslerde "İdeal Çevrim Süresi" yerine "İdeal Parti Süresi" kullanılır. Performans = (Parti Sayısı × İdeal Parti Süresi) / Çalışma Süresi. Kalite birim bazında değil parti bazında ölçülür. Durum makinesi mantığı aynı kalır, ancak zamanlama çözünürlüğü saniyelerden dakikalara kayar.

Çözüm: Ölçümden İyileştirmeye

Sağlam bir OEE sistemi, yalnızca raporlama için değil, operasyonel tanı için kurulur. Hedef yüksek puanı göstermek değil; kaybın gerçekten nerede oluştuğunu görünür kılmaktır.

Manuel ve gecikmeli raporlamadan edge tarafında hesaplanan gerçek zamanlı OEE mimarisine geçildiğinde, ekipler mikro duruşları daha erken fark eder, SKU bazlı hedefleri daha güvenilir yönetir ve makine kayıpları ile hat senkronizasyon kayıplarını daha net ayırır.

Kaynaklar

1. OEE.com - OEE Hesabı - Tercih edilen OEE formülü ve bileşenleri için pratik referans. OEE Calculation
2. ISO 22400-2 - OEE ve alt bileşenleri dahil üretim operasyon yönetimi KPI'ları standardı. ISO 22400
3. Seiichi Nakajima, "Introduction to TPM" (1988) - OEE ve Altı Büyük Kayıp çerçevesinin orijinal tanımı.
4. ISA-95 / IEC 62264 - OEE metriklerinin UNS'de yayınlanması için namespace tasarımıyla ilgili standart.
5. Hansen, Robert C., "Overall Equipment Effectiveness" (2001) - Farklı üretim ortamlarında OEE uygulaması için pratik rehber.

Gerçek OEE rakamlarınızla yüzleşmeye hazır mısınız? Proxus Edge Mimarisi'ni inceleyin, OEE yazılımı ve duruş takibi çözümümüzü keşfedin veya pilot kurulum planlamak için İletişime Geçin.