Sensörden içgörüye: DataFloem ile fabrika veri akışları

Sensör verisi neden kullanılmadan kalıyor

Tipik bir üretim hattında sıcaklığı, titreşimi, basıncı ve güç tüketimini ölçen yüzlerce sensör bulunur. Ölçümler vardır ama PLC'lere, ağ geçitlerine ve CSV dışa aktarımlarına dağılmıştır; birimleri farklıdır, boşluklar ve ani sıçramalar içerir. Biri "hangi makine sapıyor?" diye sorabilmeden önce, birinin bu veriyi elle toplaması, temizlemesi ve birleştirmesi gerekir.

Girişimlerin çoğu bu elle yapılan adımda tıkanır. Yavaştır, bir iki kişiye bağlıdır ve her yeni hat ya da sensör eklendiğinde bozulur. DataFloem bu adımı, ölçeklenebilir bir Spark kümesinde çalışan görsel ve tekrarlanabilir bir akışla değiştirir.

Senaryo

Örnek tesisimizde birkaç üretim hattı çalışıyor. Her makine birkaç saniyede bir sıcaklık, titreşim ve basınç bildiriyor. Makinelerin PLC'leri bu ölçümleri, makineler arası iletişimin endüstriyel standardı olan OPC UA üzerinden yayımlıyor. Bir toplayıcı bunları Apache Kafka'ya yazıyor. Oradan, sürekli çalışan (streaming) bir DataFloem akışı topic'i okuyor ve ölçümleri açık bir dosya ya da açık tablo formatında bir MinIO bucket'ına (S3 uyumlu) yazıyor. Bu sayfa o sürekli akış adımını ele almıyor. Burada dosyaların MinIO'ya ulaştığı yerden başlıyor ve onları saatlik sinyallere dönüştüren toplu (batch) akışı kuruyoruz.

Makine ana verileri bir PostgreSQL veritabanında tutuluyor: her makinenin hattı, modeli ve kurulum tarihi ile her sensörü için güvenli çalışma limitleri.

Ekip üç şey istiyor:

• Temiz veri: bozuk ölçümleri ayıklamak, birimleri ve zaman damgalarını tutarlı hâle getirmek.
• Bağlam: her ölçümün hangi hattan ve modelden geldiğini, her sensöre hangi limitlerin uygulandığını bilmek.
• Sinyaller: makine ve sensör başına saatlik özetler ve bir sensör limitlerinin dışında çalıştığında bir işaret.

Veriyi toplamak: OPC UA'dan Kafka'ya, oradan MinIO'ya

OPC UA, PLC üreticisi ne olursa olsun her makineye verisini yayımlamak için standart ve güvenli bir yol sunar. Kafka, üretim alanı ile analitik katman arasına dayanıklı bir tampon ekler; böylece yavaşlayan ya da duraklatılan bir akış hiçbir ölçümü kaybetmez. MinIO ise tüm geçmişi, DataFloem'in doğrudan okuduğu düşük maliyetli dosyalar olarak saklar.

1. Etiketleri yayımlayın. Her PLC ya da hattın SCADA sistemi bir OPC UA sunucusu çalıştırır. Mühendisler iş mili sıcaklığı, motor titreşimi ve hidrolik basınç gibi ilgili etiketleri (tag) açık bir düğüm hiyerarşisine yerleştirir: tesis > hat > makine > sensör.
2. Bağlantıyı güvenceye alın. Toplayıcı her OPC UA sunucusuna sertifika tabanlı kimlik doğrulama ve SignAndEncrypt güvenlik moduyla bağlanır; böylece ölçümler tesis ağında imzalanmış ve şifrelenmiş olarak taşınır.
3. Yoklamayın, abone olun. Toplayıcı, her etiket için ayrı bir örnekleme aralığıyla OPC UA abonelikleri oluşturur; örneğin titreşim için her saniye, sıcaklık için her 10 saniyede bir. Sunucu bir değeri yalnızca değiştiğinde gönderir, bu da ağ yükünü düşük tutar.
4. Uçta normalleştirin. Her ölçüm küçük bir mesaja dönüşür: makine kimliği, sensör kimliği, değer, birim, kaynak zaman damgası ve OPC UA durum kodu. Durum kodu Bad olan ölçümler atılmaz, işaretlenir; böylece onlarla ne yapılacağına akış karar verebilir.
5. Kafka'ya yayımlayın. Toplayıcı, örneğin bir Kafka Connect OPC UA kaynak bağlayıcısı ya da hafif bir uç ağ geçidi, mesajları plant.sensor-readings gibi bir topic'e yazar. Mesaj anahtarı makine kimliğidir; böylece bir makinenin tüm ölçümleri bir partition içinde sırasını korur.
6. Akışı MinIO'ya indirin. Sürekli çalışan bir DataFloem akışı topic'i kesintisiz okur ve ölçümleri MinIO'ya yazar. Bu akışın nasıl kurulduğu bu sayfanın kapsamı dışında. Önemli olan sonuç: her satırında bir ölçüm bulunan, tarihe ve saate göre bölümlenmiş JSON dosyaları, örneğin topics/plant.sensor-readings/date=2026-10-27/hour=10/. Klasörler her ölçümün kaynak zaman damgasını izler; böylece geç gelen bir ölçüm de doğru saate düşer.
7. Bir yeniden oynatma penceresi bırakın. Topic'te birkaç günlük saklama süresi, bir kesintiden sonra sürekli akışın dosyaları yeniden yazabilmesini sağlar; bucket ise makinelere yeniden dokunmadan uzun vadeli ham geçmişi saklar.

Akışı DataFloem'de kurmak

Toplama işini üretim alanı, Kafka ve sürekli çalışan bir DataFloem akışı üstlenir. İşlemenin tamamını ise toplu çalışan bir DataFloem akışı tek bir görsel işte yapar ve sonuca göre harekete geçecek kişiler için analize hazır tablolar yazar.

Akışın tamamı, DataFloem'in akış tuvalinde tek bir iştir ve kod gerektirmez. Aşağıdaki her adım, sağ tıklayarak eklediğiniz ve bir yan panelde yapılandırdığınız bir düğümdür.

1. Kaynakları bağlayın. System Architecture > Sources altında MinIO bucket'ı için bir Object Storage bağlantısı, PostgreSQL veritabanı için de bir RDBMS bağlantısı ekleyin. Kaydetmeden önce Test Connection ikisini de doğrular. Ardından bağlantıları projeye atayın.
2. Sensör dosyalarını okuyun. Object Storage bağlantısı üzerinde bir Source düğümü ekleyin ve Directory alanını, işlenecek saati belirleyen akış parametreleriyle, sürekli akışın yazdığı klasöre ayarlayın: /topics/plant.sensor-readings/date=$$run_date/hour=$$run_hour/. Örneğin run_date = 2026-10-27 ve run_hour = 10 olan parametreler Flow > Parameters altında tanımlanır; böylece her çalıştırma tamamlanmış bir saati okur. Dosya türü olarak JSON'u seçin ve şemayı doğrudan o klasördeki bir dosyadan almak için Read Columns from File seçeneğini kullanın: machine, sensor, value, unit, timestamp ve status.
3. Ölçümleri temizleyin. Bir Filter düğümü, OPC UA durumu Bad olan, değeri eksik ya da fiziksel olarak imkânsız olan ölçümleri ayıklar. Bir Expression düğümü birimleri standartlaştırır ve kaynak zaman damgasından saatlik bir zaman dilimi türetir.
4. Özetleyin. Bir Aggregation düğümü makineye, sensöre ve saate göre gruplar; her grup için ortalamayı, minimumu ve maksimumu hesaplar. Sensöre göre gruplamak sıcaklığı, basıncı ve titreşimi birbirinden ayrı tutar, çünkü bu değerlerin birlikte ortalaması alınamaz. Düğüm yalnızca gruplama anahtarlarını ve hesaplanan kolonları çıkarır; bu yüzden bağlam ondan sonra eklenir.
5. Bağlamı ekleyin ve limitleri işaretleyin. İkinci bir Source düğümü, makine ve sensör başına bir satır içeren limit tablosunu PostgreSQL'den okur. Makine ve sensör üzerinden yapılan bir Join, her saatlik özete hattı, modeli ve güvenli çalışma limitlerini ekler. Ardından bir Expression düğümü, bir sensörün minimumunun ya da maksimumunun limitlerini aştığı saatleri işaretler. Birleştirmeyi özetten sonra yapmak, join'in her ham ölçüm yerine sensör başına saatte tek bir satırla çalışması anlamına da gelir. Daha gelişmiş tespit için bir Python Scripting düğümü kendi modelinizi uygulayabilir.
6. Sonuçları yazın. Bir Target düğümü, işaretlenmiş özetleri Store Strategy Append ile bir DataFloem kataloğunda kayıtlı bir Iceberg tablosuna ya da bir raporlama veritabanına yazar. Hedefteki bir Pre Query, önce işlenen saatin satırlarını siler; böylece bir kesintiden sonra yeniden çalıştırma o saati çoğaltmak yerine yenisiyle değiştirir.
7. Önce kontrol edin, sonra çalıştırın. Data Preview ile bir Partial Run, tam çalıştırmadan önce herhangi bir düğümün çıktısını gösterir. Çalıştırmadan sonra Logs her çalıştırmanın ayrıntılarını gösterir, Versions ise akıştaki her değişikliği saklar.

Akış bir Spark kümesinde çalıştığı için aynı iş, mantığı yeniden yazmadan, yalnızca worker ekleyerek tek bir hattan tüm tesise ölçeklenir.

İşletme için anlamı

Tesis ve operasyon yöneticileri için değer akışın kendisinde değil, onun rutin hâle getirdiklerindedir:

• Daha erken uyarı, daha az duruş. Limitlerinin dışına kayan makineler bir sonraki arıza raporunda değil, saatlik veride görünür.
• Tek bir doğru kaynak. Bakım, kalite ve yönetim ayrı ayrı tutulan tablolar yerine aynı temizlenmiş ve bağlamı eklenmiş tabloları okur.
• Kişilere daha az bağımlılık. Mantık, ekipteki herkesin açıp inceleyebildiği ve değiştirebildiği, görünür ve versiyonlanan bir akışta yaşar.
• Büyümeye alan. Yeni bir hat eklemek, o hattın OPC UA sunucusunu toplayıcıya bağlamak demektir; akış aynı kalır. Yeni bir soru eklemek yeni bir proje başlatmak değil, bir düğüm eklemek demektir.
• Yerleşik yönetişim. Klasörler, projeler ve işler üzerindeki kullanıcı ve grup yetkileri ile denetim ve değişiklik günlükleri, canlı ortamdaki veriyi kontrol altında tutar.

Sonuç: “Sensör ölçtü” anından “biri harekete geçti” anına giden yol kısalır.

Çalışırken görün

Aşağıdaki video aynı akışı DataFloem tuvalinde, MinIO bucket'ını bağlamaktan saatlik özetleri önizlemeye kadar adım adım gösteriyor.