GES Datalogger Nedir? Modbus Veri Toplayıcı Seçim Rehberi
Bir GES'te izleme yazılımının gördüğü her sayı, sahada bir cihazdan okunup yukarı taşınır. O cihaz yanlış seçildiğinde yazılım tarafında hiçbir ayar bunu düzeltemez: eksik saat, kayan zaman damgası ve kopan bağlantıda kaybolan veri kalır. Bu yazı, datalogger seçimini bir "kutu" kararı olmaktan çıkarıp veri hattı tasarımı olarak ele alıyor.
Kısa Cevap
GES datalogger, inverter, sayaç, RTU ve meteoroloji istasyonlarından Modbus veya IEC 60870-5-104 ile veri okuyan, bağlantı koptuğunda yerelde yedekleyen ve buluta aktaran saha cihazıdır. Seçim dört soruya indirgenir: hangi protokolleri eşzamanlı konuşuyor, kaç cihazı hangi tur süresinde okuyabiliyor, bağlantı kesildiğinde kaç günlük veri tutuyor ve zamanını nasıl senkronize ediyor. Bu dört cevap netse, geri kalanı fiyat ve montaj meselesidir.
Datalogger'ın İşi: Veriyi Taşımak, Yorumlamak Değil
Sahada veri üç ayrı yerde doğar: inverterlerin kendi arayüzlerinde, şebeke tarafındaki sayaçta ve RTU/PLC uç noktalarında. Bu üç kaynak farklı protokoller konuşur ve çoğu zaman farklı markalara aittir.
Datalogger'ın görevi bu dağınıklığı tek bir zaman eksenine oturtmaktır. Alarm eşiği, kayıp analizi, PTF ile karşılaştırma ve görev atama yazılımın işidir. Cihazdan beklenen tek şey eksiksiz, doğru zaman damgalı ve kesintisiz veridir. Bu sınırı baştan çizmek, hem donanım hem yazılım seçimini basitleştirir.
Bir ayrımı da netleştirmek gerekir: inverterin üretmediği durum ile inverterin verisinin alınamadığı durum aynı şey değildir. İyi bir kurulumda bu ikisi panelde ayrı görünür. Aksi halde bir iletişim kopması, üretim duruşu gibi raporlanır ve yanlış ekibe görev açılır.
Üç Protokol Ailesi ve Pratik Farkları
| Protokol | Tipik kullanım | Sahada en sık yaşanan sorun |
|---|---|---|
| Modbus RTU (RS-485) | İnverter, enerji analizörü, saha sensörü | Hat uzunluğu, sonlandırma direnci, adres çakışması |
| Modbus TCP | Ethernet'li inverter ve gateway | Ağ gecikmesi, eşzamanlı bağlantı sınırı |
| IEC 60870-5-104 | Dağıtım tarafı RTU, şebeke haberleşmesi | Veri noktası listesi ve zaman damgası uyumu |
Cihazın bu üçünü aynı anda çalıştırabilmesi gerekir. Pratikte sorun, protokol desteğinin "var" görünmesi ama eşzamanlı yoklamada gecikme üretmesidir. Satın alma öncesi sorulacak doğru soru "destekliyor mu" değil, "kaç cihazı kaç saniyede okuyor" olmalıdır.
Protokol katmanının test tarafı ayrı bir iş: saha devreye alınırken register okuma ve çerçeve doğrulaması yapılmadan hiçbir alarm kuralı güvenilir değildir. Adım adım yöntem için Modbus RTU / RS485 haberleşme testi ve Modbus TCP ile RTU farkı yazılarına bakabilirsiniz.
Kaç İnverter Bir RS-485 Hattına Bağlanır?
Bu sorunun tek bir cevabı yok, çünkü belirleyen şey cihaz sayısı değil tur süresi. Tur süresi, hattaki tüm cihazların bir kez okunması için geçen zamandır ve hedef veri aralığınızı doğrudan sınırlar.
Kaba hesap şöyle yapılır:
İşlem süresi ≈ (istek baytı + yanıt baytı) × 10 bit / baud + cihaz yanıt gecikmesi
Örnek: 8 + 45 = 53 bayt, 9600 baud, 8N1
53 × 10 / 9600 ≈ 55 ms
+ 50 ms cihaz gecikmesi ≈ 105 ms (cihaz başına)
30 inverter → 30 × 105 ms ≈ 3,2 s (tek tur)
Bu hesap iki şeyi gösterir. Birincisi, 9600 baud'da 30 inverterlik bir hat 15 dakikalık veri aralığı için rahat, 1 dakikalık aralık için sınırdadır. İkincisi, hattaki cihaz sayısı arttıkça tur süresi doğrusal büyür; 60 cihaza çıktığınızda süre iki katına çıkar.
Pratik sonuçlar:
- RS-485 hattında yaygın pratik sınır 32 cihazdır. Daha fazlası için ikinci hat veya Ethernet'e geçiş gerekir.
- Baud hızını yükseltmek her zaman çözüm değildir. Uzun hatlarda ve gürültülü sahalarda yüksek hız haberleşme hatası üretir; hat uzunluğu ile hız birlikte değerlendirilir.
- Okunacak register sayısı da süreye girer. String seviyesine inmek istiyorsanız cihaz başına okunan veri miktarı artar, tur süresi uzar. Hangi veriyi hangi sıklıkta okuyacağınızı baştan tanımlamak gerekir.
Hangi Veri Aralığı Gerekli?
Veri aralığı bir tercih değil, kullanım amacının sonucudur. IEC 61724-1 standardı, performans izlemede sınıfları ayırır: Class A yüksek doğruluklu, büyük ölçekli santraller için; Class B ticari ve orta ölçekli sistemler için tanımlanmıştır (IEC 61724-1 özeti). Class A kapsamında kayıt aralığı 1 dakika veya daha kısa tutulur; üretici veri kaydedicileri de 1 Hz örnekleme ve 1 dakikalık ortalama ile bu sınıfa uyum beyan eder (Ammonit Meteo-42A).
Amaç bazlı bir başlangıç tablosu:
| Amaç | Yeterli aralık | Not |
|---|---|---|
| Üretim takibi, aylık rapor | 15 dakika | Alarm için yeterli, olay analizi için zayıf |
| O&M operasyonu, alarm | 5 dakika | Duruş ve sapma yakalamak için dengeli |
| Performans garantisi takibi | 1–5 dakika | Sözleşmede istenen çözünürlüğe göre |
| Olay sonrası inceleme | 1 dakika veya altı | Kısa süreli, geçmişe dönük saklanır |
Buradaki kritik nokta şu: 1 dakikalık veri toplamak, 1 dakikalık veri saklamakla aynı şey değildir. Cihaz 1 dakikada bir okuyup buluta gönderebilir, ama yerel hafızasında yalnızca son 3 günü tutuyorsa, iki hafta önceki bir arızanın kanıtı yoktur. Saklama süresi ayrı bir sözleşme maddesi olarak sorulmalıdır.
Zaman Damgası ve Veri Bütünlüğü
Saatlik mahsuplaşma döneminde bir saatin verisi, o saatin geliridir. Kayıp saat, kayıp gelir demektir. Bu yüzden datalogger'da üç şey zorunlu:
- Zaman senkronizasyonu. Cihaz saati NTP gibi bir kaynaktan sürekli hizalanmalı. Birkaç dakika kayan saat, raporu yanlış saate yazar ve PTF eşleştirmesini bozar.
- Yerel yedekleme. Bağlantı koptuğunda veri cihaz hafızasına yazılmalı, bağlantı gelince eksik aralık tamamlanmalı. Piyasadaki cihazlar bu konuda çok farklı: bazıları 8 GB dahili hafızayla internet kesintisinde ortalama 3 ay veri sakladığını belirtiyor (Loggma). Kendi sahanızın bağlantı kesilme süresine göre bu süreyi sorun.
- Veri boşluğu görünürlüğü. Hangi saatlerin eksik olduğu panelde görünmeli. Sessizce sıfır yazan bir grafik, en tehlikeli durumdur.
SunSpec ve Register Haritası Sorunu
Modbus desteği tek başına ortak bir veri modeli garanti etmez. İki inverter de Modbus konuşabilir ama farklı register adresleri, farklı ölçekleme katsayıları, farklı birimler ve farklı durum kodu tanımları kullanabilir. Bu yüzden entegrasyonda sürüm kontrollü register haritaları gerekir (Aforenergy).
SunSpec Modbus bu farkı azaltan bir çerçeve sunar, ancak her modelin her alanı desteklemediği unutulmamalı. Sahada karşılaşılan tipik durum şudur: aynı markanın iki farklı firmware sürümü, aynı register'ı farklı ölçekle döndürür. Bu yüzden devreye almada "değer geliyor mu" değil, "değer doğru mu" kontrol edilir.
Ağ, Erişim ve Güvenlik
Saha tarafında bağlantı çoğunlukla hücresel. Burada üç karar var:
- Erişim yöntemi. SIM bazlı bağlantıda APN ve sabit IP/özel ağ tercihleri, sahaya uzaktan erişim politikasını belirler.
- Aktarım güvenliği. Buluta aktarımda MQTT TLS gibi şifreli bir kanal ve cihaz başına kimlik kullanılmalı. Sertifika yönetimi kurulumda kurulmazsa sonradan her sahada tek tek uğraşılır.
- Yetki ayrımı. Başlangıç kapsamı salt okuma olmalı. İnverter ayarlarına yazma, uzaktan çalıştırma/durdurma ve aktif güç yönetimi ayrı bir mühendislik ve yetkilendirme süreci gerektirir; izleme kurulumuyla birlikte "hazır" gelmez.
Uzaktan firmware güncellemesi (OTA) çok sahalı portföylerde operasyonel maliyeti belirleyen kalemdir. On saha için sahaya araç çıkarmak ile tek panelden sürüm yükseltmek arasındaki fark, yıllık bakım bütçesinde görünür.
Devreye Almada Yedi Adım
- Cihaz envanteri. Marka, model, firmware sürümü ve protokol dokümanı sahada doğrulanır.
- Hat planı. RS-485 segmentleri, adresler, sonlandırma ve hat uzunluğu çizilir.
- Tur süresi ölçümü. Hedef veri aralığı için gereken süre gerçek cihazlarla ölçülür, hesapla karşılaştırılır.
- Register doğrulaması. Okunan her değer, cihazın kendi ekranı veya üretici portalıyla karşılaştırılır.
- Zaman senkronizasyonu. Cihaz saati ile platform saati arasındaki fark kontrol edilir.
- Kesinti testi. Ağ bağlantısı bilinçli olarak kesilir; verinin yerelde biriktiği ve geri geldiğinde tamamlandığı görülür.
- Alarm kuralı kalibrasyonu. İlk iki hafta gerçek veriyle eşikler ayarlanır; sürekli tetiklenen kurallar düzeltilir.
Altıncı adım en çok atlanan adımdır. Kâğıt üzerinde çalışan bir yedekleme, kesinti anında çalışmayabilir; bunu yalnızca test gösterir.
Sık Yapılan Beş Hata
- Tek hatta çok cihaz. Tur süresi hedefin üstüne çıkar, veri seyrek gelir, alarm geç tetiklenir.
- Zaman senkronizasyonunu atlamak. Rapor doğru görünür, saatler kaymıştır; PTF eşleştirmesi sessizce yanlış olur.
- Yerel hafızayı sorgulamamak. Kesinti sonrası geçmiş kaybolur, garanti ve performans tartışmasında kanıt kalmaz.
- Register haritasını sürümlememek. Firmware güncellemesi sonrası ölçek değişir, üretim rakamı bir anda yanlışlanır.
- İzleme ile kontrolü karıştırmak. İzleme kurulumu tamamlandı diye uzaktan kumanda yetkisinin de hazır olduğu varsayılır.
Sıkça Sorulan Sorular
Datalogger şart mı, inverterin kendi portalı yetmez mi?
Tek markalı ve tek sahalı bir santralde üretici portalı çoğu zaman yeterlidir. İhtiyaç, ikinci marka veya ikinci saha devreye girdiğinde ya da verinin tek bir yerde ve kendi rapor formatınızda toplanması gerektiğinde başlar. Bu ayrımı üretici portalı mı bağımsız izleme mi yazısında ayrıntılı ele aldık.
Mevcut inverterler değişmeden datalogger eklenebilir mi?
İnverterler Modbus RTU/TCP veya IEC-104 üzerinden okunabiliyorsa genellikle evet; yeni inverter gerekmez. Belirleyici olan, inverterin yerel haberleşme portunun açık olması ve register dokümanının bulunmasıdır. Bazı modellerde bu port yalnızca üreticinin kendi gateway'ine ayrılmıştır.
Kaç günlük yerel yedek yeterli?
Sahanızın bağlantı kesilme süresine bağlı. Aylık kesintisi birkaç saat olan bir sahada birkaç günlük yedek rahat yeter; kırsalda ve zayıf şebekede çalışan sahalarda haftalar mertebesinde düşünmek gerekir. Sözleşmede "kaç gün" sorusunun cevabı yazılı olsun.
Datalogger alarm üretir mi?
Kural motoru yazılım tarafındadır; cihaz veriyi taşır. Bazı cihazlarda basit eşik bildirimi bulunur, ancak alarmın göreve dönüşmesi, sahiplenilmesi ve kapanış kaydı izleme platformunun işidir. Bu zinciri GES arıza takip yazılımı yazısında adım adım anlattık.
Sonuç
Datalogger seçimi, izleme sisteminin tavanını belirler. Protokol kapsamı, tur süresi, yerel yedekleme ve zaman senkronizasyonu netleşmeden kurulan bir sistem, ekranı ne kadar iyi olursa olsun eksik veriyle çalışır. Bu dört başlığı saha keşfinde ölçün, devreye almada test edin.
Ranaliz Datalogger, Modbus TCP/RTU ve IEC 60870-5-104 ile sahayı okur, bağlantı koptuğunda veriyi cihaz hafızasına yedekler ve MQTT TLS ile platforma aktarır; firmware ve yapılandırma uzaktan güncellenebilir. Böylece saha verisi, alarm ve görev zincirinin beslendiği tek kaynağa dönüşür. Kendi sahanızın marka ve protokol dağılımına göre gereken yapılandırmayı çıkarmak için demo talep edin.
