Veri Toplama ve Analiz

Nerede işe yarıyor

Veri hattının karşılığı, tartışmayı sezgiden ölçüme taşımasında çıkıyor. “Bu hat akşam vardiyasında yavaşlıyor” cümlesi, arkasında duruş kayıtları olduğunda bir bakım planına dönüşüyor; olmadığında vardiya amirleri arasında bir görüş ayrılığı olarak kalıyor.

En sık çalıştığımız işler şunlar:

• Duruş ve OEE ölçümü. Hattın neden durduğunun sebep bazında kaydı; hangi kaybın kullanılabilirlikten, hangisinin hızdan geldiğinin ayrılması.
• İzlenebilirlik. Bir parti (batch) numarasından geriye giderek o üründe hangi tarif (recipe), hangi hammadde partisi ve hangi proses değerlerinin kullanıldığının bulunması.
• Vardiya ve üretim raporları. Elle doldurulan formların yerine, sahadan otomatik beslenen ve vardiya sonunda kendiliğinden dağıtılan raporlar.
• Enerji ve tüketim takibi. Elektrik, hava ve su tüketiminin üretim miktarıyla ilişkilendirilmesi — birim ürün başına tüketim, toplam tüketimden çok daha kullanışlı.
• Mevcut SCADA’nın üstüne raporlama kurulması. Kontrol katmanına dokunmadan, salt okuyan bir veri hattıyla.

Nasıl çalışıyoruz

İşe cevaplanacak sorunun yazılmasıyla başlıyoruz. “Verileri toplayalım” bir gereksinim değil; “her duruşun sebebini ve süresini vardiya bazında görmek istiyoruz” bir gereksinim. İkincisi hangi etiketin gerektiğini, hangi aralıkla örneklenmesi gerektiğini ve sahadan hangi girişin isteneceğini kendiliğinden belirliyor.

Ardından etiket sözlüğü geliyor: her ölçümün adresi, birimi, ölçeği, örnekleme aralığı ve ölü bandı. Bu tabloyu müşteriyle birlikte gözden geçiriyoruz, çünkü TT_014 adlı etiketin hangi tanka ait olduğunu yalnız saha ekibi biliyor.

Toplama katmanında öncelik OPC UA; PLC tarafı destekliyorsa doğrudan, desteklemiyorsa Modbus veya bir geçit (gateway) üzerinden. Sahaya dağılmış çok noktalı kurulumlarda MQTT Sparkplug B tercih ediyoruz: kopan bağlantı sonrası durum bilgisinin yeniden yayınlanması bu yapıda tanımlı, kendi elle yazacağınız bir mekanizma değil.

Veri, ham çözünürlükte bir zaman serisi veritabanına (InfluxDB veya TimescaleDB) yazılıyor; üretim özetleri, parti kayıtları ve duruş sınıflandırmaları ilişkisel tarafta (PostgreSQL) tutuluyor. Ham veri belirli bir süre sonra toplulaştırılarak saklanıyor — beş yıllık saniyelik kayıt tutmak, o kaydı hiç sorgulamayacaksanız yalnız disk maliyeti.

Pano tarafında ayrımı net yapıyoruz. Operatör panosu tek ekranda, uzaktan okunacak büyüklükte ve şu anki durumu gösterir. Vardiya panosu karşılaştırma yapar. Yönetim özeti eğilim gösterir ve tek bir sayfayı geçmez. Üç ihtiyacı tek panoya sığdırma denemesi, kimsenin açmadığı bir ekranla sonuçlanıyor.

Tesiste bir MES veya ERP varsa veri hattını onun yerine değil, yanına kuruyoruz. Genelde iki yönlü sınırlı bir alışveriş oluyor: üretim emri ve tarif bilgisi yukarıdan iniyor, gerçekleşen üretim miktarı, hurda ve tüketim aşağıdan çıkıyor. Bu arayüzü baştan dar tutmayı tercih ediyoruz — hangi alanların hangi yönde aktığı yazılı olmadan kurulan entegrasyonlar, iki sistemin aynı kaydı farklı gösterdiği tartışmalara dönüşüyor.

Dikkat ettiğimiz noktalar

Saat senkronizasyonu ilk iş. PLC, SCADA sunucusu ve veritabanı sunucusu aynı NTP kaynağına bakmıyorsa korelasyon kurulamaz: alarmın duruştan önce mi sonra mı geldiğini söyleyemezsiniz, ki duruş analizinin tamamı bu soruya dayanıyor.

Sınıflandırılmayan duruş, ölçülmemiş duruştur. Sebebi kimin, nerede ve kaç saniyede gireceği kurgulanmadan kurulan sistemlerde duruşların büyük kısmı “sınıflandırılmadı” kovasında birikiyor ve rapor anlamını yitiriyor.

Veri toplama kontrol katmanını yavaşlatmamalı. Salt okuma yapıyoruz, PLC üzerinde gereksiz abonelik bırakmıyoruz ve toplama servisi düştüğünde prosesin etkilenmediğini devreye alma sırasında test ediyoruz.

Rapor tanımı yazılı olur. “Kullanılabilirlik” hangi süreleri planlı duruş sayıyor, mola dahil mi — bu tanım dokümana geçmezse iki departman aynı ekrandan iki farklı sonuç okuyor.

Diğer çözüm alanlarıyla ilişkisi

Bu hattın kalitesi, altındaki kontrol katmanının ürettiği veriye bağlı; etiket sözlüğü düzgün kurulmamış bir sistemde raporlama katmanı yanlış sayar. Bu yüzden veri işlerini sıklıkla endüstriyel otomasyon ile birlikte planlıyoruz. Sahaya dağılmış noktaların bağlanması ve uzaktan erişim tarafı haberleşme sistemleri kapsamında; toplanan geçmiş verinin tahmin ve anomali tespiti için kullanılması ise yapay zeka ve makine öğrenmesi tarafına geçiyor — ama sırası önemli: temiz ve etiketli geçmiş veri olmadan model kurulmaz.