Uçta geçmiş veri nasıl korunur? Ara bellek, depola ve ilet, sonradan tamamlama

Verisini tesis dışına gönderen her fabrika, er ya da geç bağlantısını kaybeder. Bir fiber kablo kesilir, güvenlik duvarında bir kural değişir, merkezdeki sunucuya pazar günü güncelleme yüklenir. Bu sürede okunan değerlere ne olduğu, geçmiş verinize güvenip güvenemeyeceğinizi belirler. Trend grafiğinde iki saatlik bir boşluk can sıkar, o kadar. Ama bir OEE raporunda, enerji referans değerinde ya da parti kaydında sessizce oluşmuş bir boşluk çok daha tehlikelidir, çünkü kimse fark etmez.

Bu rehber, bu tür kesintilere rağmen geçmiş verinin eksiksiz kalmasını konu alıyor. Önce geçmiş verinin nerede saklanacağını, uçtaki ara belleğin nasıl çalıştığını ve nasıl boyutlandırıldığını anlatıyoruz. Ardından ara bellekteki veri yeniden gönderilirken gerçekte neler olduğuna ve ara belleğin kurtaramadığı boşlukların nasıl doldurulacağına geçiyoruz. Hangi ürünü kullanırsanız kullanın işinize yarayacak biçimde yazdık; Proxus'tan söz ettiğimiz yerlerde onu bir tasarımın somut örneği olarak ele alıyoruz.

Geçmiş veri üç farklı yerde tutulabilir

"Edge historian" ifadesi birbirinden oldukça farklı tasarımlar için kullanılır. Önce bunları birbirinden ayırmak gerekir.

Sahada tam bir geçmiş veri deposu

Her tesis kendi zaman serisi veritabanını çalıştırır. Tesisteki kullanıcılar ve uygulamalar doğrudan bu veritabanını sorgular. Bağlantı elverdiğinde bir çoğaltma süreci veriyi merkezdeki geçmiş veri deposuna kopyalar.

• Güçlü yanları: Kesinti sırasında yerel trendler ve raporlar çalışmaya devam eder. Çok yüksek hızdaki veri sahada kalabilir, merkeze yalnızca özetler gider.
• Bedeli: Her tesiste kurulup güncellenecek, yedeklenecek, izlenecek ve lisanslanacak bir veritabanı daha; birbirini tutmayabilecek iki ayrı geçmiş kopyası; çözülmesi gereken çoğaltma çakışmaları ve er geç dolan yerel diskler.

Sahada ara bellek, merkezde geçmiş veri deposu

Uç katman yalnızca henüz gönderilemeyen veriyi tutar, geçmiş veri deposu ise merkezdedir. Bağlantı sağlamken ara bellek neredeyse boştur. Bağlantı koptuğunda ara bellek dolar, bağlantı gelince boşalır.

• Güçlü yanları: Tek bir geçmiş veri deposu ve verinin tek bir doğru kopyası vardır. Sahada yedeklenecek bir şey kalmaz, uç donanım da küçülür.
• Bedeli: Kesinti sırasında tesisteki ekip geçmiş veriyi merkezdeki sistemden sorgulayamaz. Sahada çalışmaya devam etmesi gereken her şey buna göre tasarlanmalıdır (yerel HMI'lar kontrolörleri okumaya, uç kuralları da çalışmaya devam eder).

Karma yapı

Veriyi göndermek için ara bellek kullanılır. Tesisin kesinti sırasında mutlaka görmesi gereken birkaç bilgi (örneğin son vardiyanın sayaçları) için de küçük bir yerel depo eklenir.

Bu seçeneklerin hiçbiri her tesis için doğru değildir. Kararı şu sorular belirler: Bağlantısı kesilen bir tesis neyi görebilmeli ve neyi yapabilmeli, bu ne kadar sürebilir ve her tesisteki veritabanını kim işletecek?

Proxus ikinci tasarımı kullanır. Bir Edge Gateway, tek bir süreç ve hemen yanında ara belleği diskte tutan küçük bir mesaj sunucusundan oluşur; sahada veritabanı yoktur. Geçmiş veri deposu (sütun tabanlı bir ClickHouse deposu) ve panolar merkez sunucuda bulunur. Alarm kuralları Edge Gateway'lerde çalışır ve kesinti sırasında da devam eder; yani alarmlar bağlantıya bağımlı değildir. Tesislerinizin uzun kesintilerde yerel geçmiş veriye ihtiyacı varsa bunu projenin başında dile getirin, çünkü bu ihtiyaç tasarımı değiştirir.

Depola ve ilet nasıl çalışır?

Depola ve ilet (store and forward), uçtaki ara belleğin arkasındaki mekanizmadır. Ana hatlarıyla şöyle işler:

1. Uç katman bir değer okur ve bu değere zaman damgası ile kalite bilgisi ekler.
2. Değeri bir sonraki durağa (merkezdeki bir mesaj sunucusu, bir MQTT sunucusu ya da bir veritabanı) iletmeye çalışır.
3. Sonraki durak değeri kabul ederse uç katmanın o değerle işi biter. Kabul etmezse değer yerel ve kalıcı bir kuyruğa yazılır.
4. Sonraki durağa yeniden ulaşıldığında kuyruk en eskiden başlayarak sırayla gönderilir; bu sırada yeni değerler de gelmeye devam eder.
5. Bir değer, ancak sonraki durak onu aldığını onayladıktan sonra kuyruktan silinir.

Ara belleği güvenli kılan 5. adımdır. Bir mesajı onaylandığında değil de gönderildiğinde silen bir ara bellek, bağlantı koptuğu anda yolda olan her şeyi kaybeder.

Önemli olan özellikler

Bir ara belleği değerlendirirken şu soruları sorun:

Proxus'ta durum şöyledir: Ara bellek, Edge Gateway'in mesaj sunucusunda diskte tutulur. Saklama süresi her Edge Gateway için Ara bellek saklama süresi (saat) alanından ayarlanır; varsayılan değer 48 saattir ve 1 ile 720 saat (30 gün) arasında herhangi bir değere ayarlanabilir. Bu sınır aşıldığında önce en eski veri silinir. Değerler merkez sunucuya okundukları zamanla ulaşır. Uçta oluşan alarmlar da aynı şekilde ara belleğe alınır ve oluştukları sırayla gönderilir. Veritabanları, MQTT, Kafka, REST, InfluxDB, bulut IoT servisleri ve diğerleri dâhil her veri hedefi türünün Edge Gateway'de, aynı saklama süresine sahip kendi kalıcı kuyruğu vardır. Hedef yeniden erişilebilir olduğunda kuyruk sırasıyla ve en az bir kez yazılır. Her hedefin durum bilgisi son başarılı gönderimi, son başarısız denemeyi ve son hata mesajını gösterir; hedefe ulaşılamadığı sürece kuyrukta kaç mesajın beklediği de görülür. Bu yolun ayrıntıları veri akışı sayfasında anlatılıyor.

Ara belleği boyutlandırmak

Ara bellek, atlatmayı hedeflediğiniz en uzun kesinti boyunca okunan bütün veriyi tutabilmelidir. Hesap basittir; hatalar genellikle hesaba giren değerlerde yapılır.

Adım 1: Veri hızını ölçün. Veri noktalarını değil, saniyede okunan değer sayısını sayın. Her saniye okunan bin veri noktası saniyede bin değer üretir; aynı veri noktaları on saniyede bir okunursa saniyede yüz değer çıkar. Cihazların kendiliğinden gönderdiği değerleri ve alarmları da bu sayıya ekleyin.

Adım 2: Diskte değer başına kaç bayt harcandığını ölçün. Bu değer veri kodlamasına, her değerle birlikte saklanan ek bilgiye ve kuyruğun kendi yüküne bağlıdır. Bir sayının boyutuna bakarak tahmin etmeyin. Bir test Edge Gateway'inde bağlantıyı keserek sistemi belirli bir süre çalıştırın ve ara belleğin ne kadar büyüdüğüne bakın.

Adım 3: Kesinti süresini belirleyin. O tesiste kopan bir bağlantıyı onaracak birini bulmanın, hafta sonları ve bayramlar dâhil, gerçekte ne kadar sürdüğünü sorun. Kendi IT ekibi olan bir fabrika için bir gün yetebilir. Tek bir teknisyenin gidip geldiği uzak bir pompa istasyonu için haftalar gerekebilir.

Adım 4: Çarpın ve pay bırakın.

buffer size = values per second × bytes per value × seconds of outage × headroom

Formülde ara bellek boyutu; saniyedeki değer sayısı, değer başına bayt, kesinti süresi (saniye) ve güvenlik payının çarpımıdır. Aşağıdaki örnekte varsayımsal rakamlar kullanıldı; bunları kendi ölçümlerinizle değiştirin:

Bu hesaptan genellikle iki sonuç çıkar. Birincisi, yüksek veri hızı ile uzun kesinti süresi bir araya geldiğinde ciddi disk alanı gerekir. Bir aylık ara bellek sözü vermeden önce uç donanımı mutlaka kontrol edin. İkincisi, ara belleği küçültmenin en ucuz yolu çoğu zaman daha az okumaktır. Kimsenin o çözünürlükte kullanmadığı, 100 milisaniyede bir okunan bir veri noktası, saniyede bir okunan aynı veri noktasına göre on kat disk harcar.

Ara belleğin hangi sınıra tabi olduğunu da kontrol edin. Proxus'ta bir Edge Gateway'in lisanslı veri hızını aşan veri ne gönderilir ne de ara belleğe alınır. Bu yüzden lisans, yeniden başlatma sonrasındaki ani yükselişler dâhil gerçek veri hızını karşılamalıdır.

Veri yeniden gönderilirken gerçekte ne olur?

Ara bellek tasarımlarının çoğu "veri ulaşıyor mu?" sorusuyla test edilir, "ulaştığında nasıl görünüyor?" sorusuyla değil. Oysa yeniden gönderimin, veriyi kullanan sistemlerin hazırlıklı olması gereken yan etkileri vardır.

Veri geç ve topluca gelir

Altı saatlik bir kesintinin ardından altı saatlik veri, canlı veriyle karışık olarak birkaç dakika ya da birkaç saat içinde gelir. Verinin geliş zamanını olayın zamanı sayan her sistem, veriyi yanlış zamana yerleştirir. Veriyi kullanan her sistem, mesajın içindeki zaman damgasını esas almalıdır.

Panolar ve raporlar genellikle sorun çıkarmaz, çünkü geçmiş veri deposundan zaman damgasına göre okurlar. Asıl risk, mesajlara geldikleri anda tepki veren bileşenlerdedir. Aldığı her alarm için e-posta gönderen bir betik, altı saatlik alarmı bir anda gönderir. Yeniden gönderilen olayların bir eylemi tetikleyip tetiklemeyeceğine karar verin; tetiklememeleri gerekiyorsa zaman damgasının yaşına göre filtreleyin.

Mükerrer kayıtlar oluşur

"En az bir kez" iletim şu anlama gelir: Bir değer karşıya ulaştıktan sonra ama onay geri dönmeden bağlantı koparsa değer yeniden gönderilir. Çözüm alıcı taraftadır: Yazma işlemlerini idempotent, yani tekrarlandığında sonucu değiştirmeyecek şekilde kurun. Geçmiş veri deposu ya da bir veritabanı hedefi cihaz, veri noktası ve zaman damgasını anahtar olarak kullanmalıdır; böylece ikinci kopya yeni bir satır eklemez, ilkinin üzerine yazar. Hedef sistem bunu yapamıyorsa mükerrer kayıtları sorgu aşamasında ayıklayın.

Canlı veri birikmiş veriyle yarışır

Birikim boşalırken bağlantı hem eski hem yeni veriyi taşır. Bağlantı yavaşsa birikim bitene kadar canlı değerler merkeze gecikmeli ulaşır. Gerçek bağlantınızda birikimin tamamen boşalmasının ne kadar sürdüğünü bilin ve test edin. İki günlük kesintiyi üç günde boşaltan bir ara bellek, işin altından kalkamıyor demektir.

Uçtaki kurallar beklemez

Sahada çalışan alarm kuralları kesinti boyunca değerlendirme yapmaya devam eder ve alarmlarını yerelde üretir. Bu alarmlar da birikimin bir parçasıdır. Alarmları takip eden ekiplerin, bağlantı geri geldiğinde topluca düşen alarmların yeni bir olay değil geçmişe ait kayıtlar olduğunu bildiğinden emin olun.

Ara bellek yetmediğinde veri sonradan tamamlanır

Ara bellek, Edge Gateway'den sonraki yolu korur. Hiç okunmamış değerleri ise geri getiremez. Edge Gateway kapalı olabilir, makinenin ağı çökmüş olabilir, cihaz henüz bağlanmamış olabilir ya da kesinti saklama süresinden uzun sürmüş olabilir. Bu boşluklar için sonradan veri tamamlama (backfill) gerekir, yani geçmiş değerlerin olaydan sonra başka bir kaynaktan yüklenmesi.

Eksik veri nereden bulunur?

• Aralıklı kayıt tutan enerji sayaçları gibi kendi belleği olan veri kaydediciler ve sayaçlar.
• Trend belleği ya da reçete ve parti kaydı tutan kontrolörler.
• Merkezdeki sistemin kaçırdığını kaydetmiş olabilecek makinenin kendi HMI'ı ya da SCADA historian'ı.
• Üreticinin bir aracından ya da laboratuvar sisteminden alınan CSV dışa aktarımları.

Güvenli veri tamamlamanın kuralları

1. Özgün zaman damgalarını koruyun ve hangi saate göre olduklarını belirtin. Kaydedicinin saati yerel saate göre çalışıyor ya da gerçek saatten kaymış olabilir. İçe aktarmadan önce zamanları UTC'ye çevirin ve bilinen kaymaları düzeltin.
2. Her içe aktarımı idempotent yapın. İçe aktarımlar yarıda kesilir ve yeniden denenir. Her pakete değişmeyen bir anahtar verin (örneğin kaynak dosya adı ve paket numarası); böylece aynı paket iki kez gönderilse de sonuç değişmez.
3. Küçük paketlerle aktarın. Tek seferde yapılan büyük yüklemeler zaman aşımına takılır, yeniden denemeyi de pahalı hâle getirir.
4. Sağlam canlı veriyi sonradan tamamlanan veriyle ezmeyin. Aynı zaman için ikisi birden varsa hangisinin geçerli olacağına önceden karar verin. Genellikle canlı değer geçerli sayılır, sonradan tamamlama yalnızca eksikleri doldurur.
5. Kaynağı işaretleyin. Bir zaman aralığındaki verinin sonradan tamamlandığını, nereden ve ne zaman geldiğini kaydedin. İleride trende bakan bir denetçi ya da mühendis bunu görebilmelidir.
6. Bu veriye bağlı hesapları yenileyin. Boşluk süresince hesaplanan OEE, enerji toplamları ve vardiya raporları o veri olmadan hesaplandı. Etkilenen dönem için bunları yeniden çalıştırın.

Proxus'ta bunun için bir geçmiş veri içe aktarma uç noktası bulunur. Bir program, bir cihazın geçmiş okumalarını HTTP üzerinden en fazla 50 kayıtlık paketler hâlinde geçmiş veri deposuna gönderir. Her pakette bir Idempotency-Key bulunduğu için yeniden denemek güvenlidir. Değerler trendlerde, raporlarda ve Telemetry API'de canlı verinin yanında görünür. Bu uç nokta varsayılan yapılandırmada kapalıdır ve bilinçli olarak açılması gerekir; geçmiş veriye yazan bir uç nokta için doğru varsayılan da budur.

Boşlukları başkasından önce siz bulun

Kendi fark ettiğiniz bir boşluk, sıradan bir bakım işidir. Denetçinin bulduğu boşluk ise bir denetim bulgusudur. Bu yüzden tespiti sistemin içine kurun.

• Her cihazın en son ne zaman veri gönderdiğini izleyin. Son değeri birkaç okuma aralığından daha eski olan bir cihaz veri göndermiyor demektir. Unified Namespace yapısında bu bilgi genellikle her cihaz için saklanan (retained) bir durum konusunda tutulur.
• Her Edge Gateway ve her hedef için birikimi izleyin. Bağlantı sağlamken büyüyen bir birikim, hedefin gelen veriye yetişemediğini gösterir.
• Geçmiş veri deposunda her cihaz için saatlik değer sayısını kontrol edin. Bu sayıyı okuma aralığına göre beklenen sayıyla karşılaştırın. Eksik çıkan her dönem, incelenmesi gereken bir aralıktır. Bunu gözle değil, zamanlanmış bir sorguyla yapın.
• Sessizlik için alarm kurun. Bir sinyalin sabit kalmasını (flatline) ya da kesilmesini yakalayan bir alarm kuralı, eşiklerin hiçbir zaman yakalayamayacağı sorunları ortaya çıkarır; çünkü gelmeyen bir değer hiçbir eşiği aşmaz. Proxus anomali kuralları bu yüzden sabit kalma ve veri boşluğu tespitini de içerir.

Bütün yolu test edin

Testi yazılı hâle getirin; devreye almadan önce ve her büyük değişiklikten sonra tekrarlayın.

Kontrol listesi

• Geçmiş verinin nerede (sahada, merkezde ya da her ikisinde) tutulacağına ve bir tesisin kesinti sırasında neleri görmeye devam etmesi gerektiğine karar verdiniz.
• Ara bellek diskte duruyor, özgün zaman damgalarını koruyor, veriyi sırasıyla gönderiyor ve yalnızca onay geldikten sonra siliyor.
• Saklama süresi ölçülmüş veri hızına, değer başına bayt miktarına ve tesisle üzerinde anlaşılan kesinti süresine göre belirlendi.
• Yalnızca merkez bağlantısı değil, her veri hedefinin verisi ara belleğe alınıyor ya da veri kaybı durumunda ne olacağı biliniyor.
• Veriyi kullanan sistemler mesajın içindeki zaman damgasını esas alıyor; yazma işlemleri idempotent olduğu için mükerrer kayıtlar zarar vermiyor.
• Birikim ve cihazların son veri gönderme zamanı izleniyor; sessizlik alarm üretiyor.
• İdempotent paketlerle çalışan ve neyin sonradan tamamlandığını kaydeden yazılı bir veri tamamlama prosedürü var.
• Yukarıdaki kesinti testleri yapıldı ve sonuçları saklandı.

İlgili yazılar

• IIoT'de depola ve ilet: yaklaşımın kısa bir özeti.
• Uç bilişim desenleri: ara belleğe almanın yerel kararlar ve çoklu hedefe dağıtımla birlikte kullanımı.
• Uç bilişimde akıllı filtreleme: daha az okuyup daha az göndermenin ayrıntı açısından bedeli.
• Bugün AVEVA PI System mı kullanıyorsunuz? Proxus ve AVEVA PI System karşılaştırması, bir operasyon geçmiş veri deposuyla bir veri toplama ve aktarım katmanının işi nasıl paylaştığını ve ikisinin birlikte nasıl çalıştığını anlatıyor.
• Proxus dokümantasyonunda: Veri nasıl akar?, Edge Gateway'leri yönetmek, Veri hedefleri, Geçmiş veri içe aktarma ve Edge Gateway sorunlarını gidermek.