Gerçek Zamanlı OEE Hesaplama Rehberi: Excel Tablolarını Bırakma Vakti

Bugün bir fabrika müdürünün odasına girip OEE (Toplam Ekipman Etkinliği) değerlerini sorarsanız, size muhtemelen bir beyaz tahta gösterecek veya önemli bir Excel dosyası açacaktır. "Geçen hafta," diyecektir gururla, "yüzde 72 ile çalıştık."

Yarı iletken üretim ortamlarında, manuel raporlar "OEE %76" gösterebilir. Ancak saniyede çözünürlükte real-time telemetri incelendiğinde, 3-5 dakikalık "mikro duruşlar" manuel raporlarda hiç görülmez. Gerçek OEE %61 olabilir. O %15 fark, milyonlarca dolarlık yıllık verimlilik kaybı anlamına gelebilir.

Bu oran, üretim gerçeğinin tam resmini yansıtmayabilir.

Geleneksel üretim anlayışında OEE, vardiya sonrası hesaplanan gecikmeli (lagging) bir KPI'dır. Operatör girişlerine dayalı 15 dakikalık yuvarlama yaklaşımı, 3-5 dakikalık mikro duruşları çoğu zaman kaçırır. Bu nedenle manuel OEE, operasyonel darboğazları çözmek için gereken yüksek çözünürlüğü sağlayamayabilir.

Gerçek dijital dönüşüm, Gerçek Zamanlı OEE (Real-Time OEE) gerektirir. Bu sadece şık bir dashboard grafiğinden ibaret değildir; üretim verimsizliklerini ortaya çıkaran yüksek çözünürlüklü bir analiz aracıdır.

Bu rehberde basit formüllerin ötesine geçiyoruz. Birleşik İsim Alanı (UNS) mimarisini kullanarak gerçek zamanlı bir OEE motorunu nasıl kurgulayacağınızı, kompleks hat durumlarını (Örn: Besleme Yok - Starved, Çıkış Tıkalı - Blocked) Edge (Uç bilişim) tarafında nasıl yöneteceğinizi ve Excel'in genellikle göremediği "görünmez" kayıpları Proxus ile nasıl yakalayacağınızı derinlemesine inceleyeceğiz.

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.

OEE hesaplaması sahada (Edge'de) yapılmalıdır.

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 (micro-stop) kaçırmamak için hesaplama gücünün makinenin hemen yanındaki lokal ağda olması şarttır.

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.

Asıl Kazanç Kapısı: Mikro Duruşları Yakalamak

Gerçek yatırım getirisini (ROI) sağlayacağınız yer tam olarak burasıdır. "Mikro Duruş", genellikle 2-5 dakikadan kısa süren hatalardır. Sensör hafifçe kirlenir, parça sıkışır; operatör eliyle düzeltir, makineyi resetler ve üretime devam eder. Bu tür duruşlar "Kayıp" veya "Arıza" defterlerine hiçbir zaman işlenmez.

Ancak bir makine bir vardiyada 40 kez, 30 saniyeliğine duruyorsa; günün sonunda toplam 20 dakikalık saf üretim kaybetmişsiniz demektir.

C# ile Mikro Duruş Tespiti

Proxus Kural Motorunu (Edge Scripting) kullanarak bu kaçakları saniyesi saniyesine otomatik tespit edebiliriz. Uçta koşan örnek bir script:

// Proxus Edge SDK: Mikro Duruş Dedektörü
// FunctionBase sınıfından türetilmiş bir Edge Fonksiyonu

public class MicroStopDetector : FunctionBase {

 private DateTime _lastStopStart;
 private bool _isStopped;
 private const double MICRO_STOP_THRESHOLD = 120.0; // saniye

 public MicroStopDetector(object sys, object log, object cfg)
 : base(sys, log, cfg) { }

 protected override void OnStarted() {
 // Tüm yerel cihazlardaki TransportData mesajlarına abone ol
 Subscriptions?.Add(new SubscriptionContext {
 Type = typeof(TransportData),
 Topics = (HashSet<string>) ["*"]
 });
 base.OnStarted();
 }

 protected override void OnMessageReceive(FunctionContext ctx) {
 if (ctx.Message is TransportData data) {
 var state = data.GetPayloadValueByName<string>("State");

 if (state == "STOPPED" && !_isStopped) {
 _lastStopStart = DateTime.Now;
 _isStopped = true;
 }
 else if (state == "RUNNING" && _isStopped) {
 var duration = (DateTime.Now - _lastStopStart).TotalSeconds;
 var category = duration < MICRO_STOP_THRESHOLD
 ? "MicroStop" : "Downtime";

 // UNS üzerine MQTT yayını
 PublishMqttMessage(
 $"Line1/OEE/Losses/{category}",
 duration.ToString("F1"));

 LogInformation(
 $"{category} detected: {duration:F1}s");

 _isStopped = false;
 }
 }
 base.OnMessageReceive(ctx);
 }
}

Elde edilen MikroDurus_Suresi verisini MQTT (UNS) üzerine yayınlayarak, bu mikro duruşların günün hangi saatlerinde yığıldığını analiz eden ısı haritaları çıkartabilirsiniz. Çoğu zaman bunların hammadde değişimi veya vardiya başı molalarına denk geldiğini acı bir şekilde fark edeceksiniz.

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 yarı iletken endüstrisinden (SEMI E10) çıkmıştı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 sistemleri doğası gereği yuvarlama ve örnekleme sınırlarına (sampling bounds) takılır - mikro duruşların gözden kaçması veya aradan geçen sürenin tam kaydedilememesi sık rastlanan durumlardır. Bu durum bir hata değil, manuel izlemenin fiziksel bir sınırıdır. Makinenin dijital sensör durumu hesaplamayı doğrudan yönettiğinde, bu ölçüm sınırları kalkar. Otomatik OEE ilk kurulduğunda manuel versiyondan 5–15 puan düşük çıkabilir - bu fark, dijital sistemin sağladığı yüksek çözünürlüğün (yakalanan mikro duruşların) bir sonucudur ve sürekli iyileştirme için mükemmel bir temel oluşturur.

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

OEE neyi kaybettiğinizi ölçer; Gerçek Duruş Maliyeti (TDC) ne kadar para kaybettiğinizi ölçer. İkisi tamamlayıcıdır. Saatlik TDC'si 50.000$ olan bir makinede Kullanılabilirlikte %1'lik iyileşme, günde yaklaşık 4.000$ kurtarılmış gelire dönüşür.

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 Sürekli İyileştirmeye (Kaizen)

Sistematik bir OEE ölçümü, şirketinizin üretim raporu değil, tanı aracıdır. Amaç, yüksek puan yakalayıp kağıt üstünde yöneticilere şirin görünmek değil; prosesinizin arkasına saklanmış verimsizlikleri tespit edebilmektir.

Excel süreçlerini bırakıp Uç Bilişim tarafından hesaplanan, Gerçek Zamanlı bir OEE Mimarisi'ne geçtiğiniz anda, dikiz aynasına değil ön camdan yola bakmaya başlarsınız. Mikro duruşları büyük arızalara dönüşmeden yakalarsınız. Hedefleri SKU bazında dinamik ayarlarsınız. Operatörler, makinenin - formla değil - ürettiği veriye güvenir.

Kaynaklar

1. SEMI E10 - Ekipman Güvenilirliği, Kullanılabilirliği ve Bakılabilirliği (RAM) tanım ve ölçüm spesifikasyonu. SEMI Standards
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 & Duruş Analizi çözümümüzü keşfedin veya pilot kurulum planlamak için İletişime Geçin.