Üretim Verisinde Zaman Damgası ve Veri Kalitesi: Hatalar ve Çözümler

Yanlış değer trendde hemen göze batar. Yanlış zaman damgası batmaz. Bir alarmın, onu tetikleyen basınç artışından iki saniye önce kaydedildiği ancak kök neden analizinde, yanlış sonuca varıldıktan sonra anlaşılır. Aşağıda veri toplama zincirinde üretim verisi zaman damgasının ve kalite bilgisinin nerede bozulduğunu, sahada nasıl tespit edildiğini ve hangi ayarlarla önlendiğini anlatıyoruz; hedef okur IIoT, historian ve MES projelerinde çalışan ekipler.

Kaynak ve sunucu zaman damgası farkı

Bir değer sensörden historian’a ulaşana kadar birkaç katmandan geçer: PLC, gateway veya OPC UA sunucusu, toplayıcı, veritabanı. Her katman değere kendi zaman damgasını ekleyebilir. OPC UA bu ayrımı açıkça modeller: bir DataValue yapısında değerin yanında SourceTimestamp (değerin kaynakta oluştuğu veya değiştiği an), ServerTimestamp (sunucunun değeri aldığı veya güncellediği an) ve StatusCode taşınır.

Sorun, zincirdeki bir katmanın kaynak zaman damgasını atıp kendi zamanını yazmasıyla başlar. Sahada en sık gördüğümüz örnekler:

• Toplayıcı OPC UA’dan gelen değeri veritabanına yazarken SourceTimestamp yerine kendi “şimdi” değerini kullanır.
• Gateway bağlantı kesintisi sonrası tampondaki veriyi gönderirken her kayda gönderim anını yazar; bir saatlik veri birkaç saniyeye sıkışır.
• MQTT yükünde zaman damgası yoktur; broker’dan okuyan servis mesajın geliş zamanını kullanır.
• PLC değeri periyodik okunur ve okunma zamanı kaydedilir; değişimin okuma aralığının neresinde olduğu bilinmez.

Kural basit: olayın zamanı, olaya en yakın katmanda damgalanmalı ve zincir boyunca değiştirilmeden taşınmalıdır. Alınma zamanı da saklanacaksa ayrı bir alana yazılır. İki zaman arasındaki fark, gecikme ve tamponlama sorunlarının en iyi göstergesidir. Bu farkı izleyen ekip, sorunu operatör şikâyet etmeden görür.

Saat kayması ve zaman senkronizasyonu: NTP mi PTP mi

Kaynak zaman damgası ancak kaynağın saati doğruysa işe yarar. Senkronize edilmeyen PLC, HMI paneli, gateway ve sunucuların saatleri günler içinde saniyeler, aylar içinde dakikalar düzeyinde kayabilir. Saati elle ayarlanan bir PLC, yaz saati değişikliğinde veya pil değişiminden sonra tamamen yanlış bir zamana düşebilir. Kimse fark etmez.

Ölçüt	NTP	PTP (IEEE 1588)
Tipik doğruluk (LAN)	Milisaniye düzeyi	Donanım damgalamayla mikro saniye altı
Altyapı gereksinimi	Standart ağ, NTP sunucusu	PTP destekli switch’ler (boundary/transparent clock), grandmaster
Cihaz desteği	PLC, HMI, sunucu, gateway’lerde yaygın	Daha sınırlı, donanıma bağlı
Uygun kullanım	Historian, OEE, MES, olay kaydı	Olay sıralaması, enerji sistemleri, hareket kontrolü

Çoğu üretim verisi uygulaması için NTP yeterlidir. Önemli olan tüm cihazların aynı zaman kaynağına bağlanmasıdır: OT ağında, tercihen GPS veya üst katman bir NTP kaynağından beslenen yerel bir NTP sunucusu kurulur ve PLC, HMI, gateway, historian ve MES sunucuları buna yönlendirilir. NTP’nin davranışı RFC 5905’te tanımlıdır. Ağ düzeyinde hassas zaman senkronizasyonu gereken durumlar TSN ve zaman senkronizasyonu yazısında ele alınıyor.

Senkronizasyon durumunu doğrulamak için:

# Linux (chrony): seçili kaynak ve sapma
chronyc tracking
chronyc sources -v

# Windows: senkronizasyon durumu ve kaynak
w32tm /query /status
w32tm /stripchart /computer:ntp.ot.local /samples:5 /dataonly

PLC tarafında CPU’nun NTP istemcisinin etkin olduğu ve sunucu adresinin doğru girildiği proje ayarlarından kontrol edilir. Sık rastlanan hata, NTP sunucusunun adresinin girilmiş ama OT firewall’ında UDP 123’ün PLC hücresine açılmamış olmasıdır. PLC saatini bir tag olarak okuyup sunucu saatiyle karşılaştıran basit bir kontrol, kaymayı erken yakalar.

Kalite kodları ve iyi/kötü/belirsiz veri

OPC UA’da her değerin bir StatusCode’u vardır. Kodun en üst iki biti önem derecesini belirtir: Good (0x0…), Uncertain (0x4…) ve Bad (0x8…). Alt alanlar nedeni taşır; örneğin Bad_NoCommunication kaynağa ulaşılamadığını, Bad_WaitingForInitialData henüz değer gelmediğini, Uncertain_LastUsableValue son kullanılabilir değerin taşındığını gösterir. Kod listesinin tamamı OPC UA spesifikasyonunda yer alır (OPC Foundation çevrim içi referansı).

Kalite bilgisinin analizde kaybolmaması için:

• Historian şemasında değerin yanında kalite alanı olmalı; en azından iyi/belirsiz/kötü ayrımı saklanmalıdır.
• Kötü kaliteli kayıtlar atılmamalı, işaretlenmelidir. Atılan kayıt, veri boşluğunun nedenini de siler.
• Özet ve hesaplama sorgularında kötü kaliteli değerler varsayılan olarak hariç tutulmalı, belirsiz değerlerin nasıl ele alınacağı tanımlanmalıdır.
• Protokol dönüşümünde kalite korunmalıdır. Modbus gibi kalite bilgisi taşımayan bir kaynaktan gelen değer için gateway, iletişim hatasında değeri “iyi” göstermeye devam etmemelidir.

Son madde sahada en çok can yakanıdır. Kablo kopmuş, gateway son okunan değeri “iyi” kalitesiyle yayımlamaya devam ediyor. Ekranda her şey normal.

Deadband ve örneklemenin analize etkisi

OPC UA aboneliklerinde iki ayrı parametre vardır: sampling interval (sunucunun kaynağı ne sıklıkta örnekleyeceği) ve publishing interval (bildirimlerin istemciye ne sıklıkla gönderileceği). Bunlara ek olarak veri değişim filtresiyle mutlak veya yüzdesel deadband tanımlanabilir. Analizdeki etkileri:

• Örnekleme aralığından kısa süren bir tepe değer hiç görülmez. 1 saniyede bir örneklenen bir akım sinyalinde 200 ms’lik bir sıçrama kaydedilmeyebilir.
• Deadband kullanılan bir tag’de ardışık iki kayıt arasındaki düz çizgi “değer sabitti” demek değildir; “değer deadband içinde kaldı” demektir. Trend aracının iki nokta arasını basamak mı doğrusal mı çizdiği bu yorumu değiştirir.
• Üretim izleme dashboard’larındaki ortalamalar eşit aralıklı olmayan veride basit aritmetik ortalamayla hesaplanırsa, sık değişen dönemler fazla ağırlık kazanır. Zaman ağırlıklı ortalama kullanılmalıdır.
• Sayaç ve durum sinyallerinde deadband kullanılmaz; her değişim kaydedilir.

Veri boşlukları ve kesinti tespiti

Deadband kullanan sistemde “veri gelmiyor” iki anlama gelebilir: değer değişmiyor ya da bağlantı kopuk. Ayırt etmek için şu yöntemlerden en az biri kurulmalıdır:

• Toplayıcının her kaynak için bağlantı durumunu ayrı bir tag olarak yayımlaması.
• PLC’de her saniye artan bir canlılık sayacının (heartbeat) okunması; sayaç artmıyorsa kaynak veya bağlantı sorunludur.
• Sparkplug B gibi doğum ve ölüm (birth/death) mesajlarıyla durum bildiren bir protokolün kullanılması.

Geçmiş veride boşlukları bulmak için pencere fonksiyonları kullanılır. Aşağıdaki PostgreSQL/TimescaleDB sorgusu son bir günde tag başına 5 dakikadan uzun boşlukları listeler:

SELECT tag_id, onceki, time AS sonraki, time - onceki AS bosluk
FROM (
  SELECT tag_id, time,
         lag(time) OVER (PARTITION BY tag_id ORDER BY time) AS onceki
  FROM tag_data
  WHERE time > now() - INTERVAL '1 day'
) t
WHERE time - onceki > INTERVAL '5 minutes'
ORDER BY bosluk DESC;

Eşik tag bazında belirlenir: her saniye değişen bir heartbeat tag’inde 10 saniyelik boşluk bir kesintidir, deadband’li bir sıcaklık tag’inde 5 dakika olağan olabilir. Toplayıcının tamponlama (store and forward) özelliği kesintide veriyi koruyorsa, geriye dönük yazılan kayıtların kaynak zaman damgasıyla geldiği bu sorguyla doğrulanır. Doğrulamanın en temiz yolu bilinçli bir kesinti yaratmaktır: toplayıcının ağ bağlantısını birkaç dakika kesin, sonra boşluğun dolup dolmadığına bakın. Tamponlama ve gateway seçimi ayrıntıları için edge gateway seçimi yazısına bakabilirsiniz.

Örnek hata senaryoları tablosu

Belirti	Olası neden	Çözüm
Alarm, tetikleyen olaydan önce görünüyor	Farklı cihaz saatleri senkron değil	Tüm cihazları aynı NTP kaynağına bağla, sapmayı izle
Kesinti sonrası çok sayıda kayıt aynı saniyede	Tampon gönderiminde kaynak zaman damgası kayboluyor	Toplayıcıda kaynak zamanını koru, alınma zamanını ayrı sakla
Her yıl aynı tarihte bir saatlik çakışma	Yerel saatle saklama, yaz saati geçişi	Tüm katmanlarda UTC kullan
Bağlantı koptuğu halde trend düz devam ediyor	Gateway son değeri iyi kalitede taşıyor	Kalite kodunu aktar, bağlantı durumu tag’i ekle
Kısa tepe değerler trendde yok	Örnekleme aralığı veya sıkıştırma toleransı geniş	Kritik tag’de aralığı daralt veya PLC’de tepe değeri yakala
OEE vardiya sınırında tutarsız	PLC ve MES saatleri farklı	Saat senkronizasyonu ve UTC; vardiya sınırını tek yerde hesapla

Veri kalitesi kontrol listesi

• OT ağında tek bir zaman kaynağı var; PLC, HMI, gateway ve sunucular buna senkron.
• Saat sapması periyodik olarak ölçülüyor ve eşik aşımında uyarı üretiliyor.
• Kaynak zaman damgası zincir boyunca korunuyor; alınma zamanı ayrı alanda saklanıyor.
• Tüm zaman damgaları UTC; yerel saat yalnız gösterimde.
• Her kayıtla birlikte kalite bilgisi saklanıyor; kötü kaliteli kayıtlar atılmıyor.
• Sayaç ve durum sinyallerinde deadband yok; analog sinyallerde deadband ölçüm belirsizliğine göre seçildi.
• Her kaynak için bağlantı durumu veya heartbeat tag’i var.
• Veri boşlukları düzenli bir sorgu veya raporla tespit ediliyor.

OEE ve kök neden analizinin güvenilirliği bu listedeki maddelere doğrudan bağlıdır. Zaman damgası yanlışsa analiz de yanlıştır. OEE tarafındaki etkiler OEE hesaplaması için doğru veri kaynakları yazısında anlatılıyor. Veri toplama zincirinin tasarımı ve doğrulanması için IIoT ve üretim verisi toplama hizmetimize bakabilirsiniz.

Sık sorulan sorular

Historian’da hangi zaman damgası saklanmalı: kaynak mı, sunucu mu?

Analizde kaynak zaman damgası esas alınır, çünkü olayın gerçekleştiği anı temsil eder. Mümkünse sunucu veya alınma zamanı da ayrı bir alanda saklanır; ikisi arasındaki fark gecikme ve tamponlama sorunlarını teşhis etmeye yarar. Kaynak zaman damgası güvenilmezse, örneğin cihaz saati senkron değilse, bu durum açıkça işaretlenmelidir.

PLC’lerde NTP yeterli mi, PTP gerekli mi?

Veri toplama, OEE ve olay sıralaması için NTP’nin sağladığı milisaniye düzeyindeki doğruluk çoğu durumda yeterlidir. Farklı cihazlardaki olayların mikro saniye düzeyinde sıralanması gerekiyorsa, örneğin enerji sistemlerinde olay kaydı veya hareket kontrolü analizinde, donanım destekli PTP gerekir.

Kalitesi kötü olan değerler historian’a yazılmalı mı?

Yazılmalı, ama kalite bilgisiyle birlikte. Kötü kaliteli kaydı atmak, o aralıkta verinin neden olmadığını sonradan anlamayı imkânsız kılar. Raporlama ve hesaplama tarafında ise kötü ve belirsiz kaliteli değerlerin nasıl ele alınacağı açıkça tanımlanmalıdır.

Deadband kullanılan bir tag’de veri gelmemesi bağlantı kopması mı demektir?

Tek başına hayır; değer deadband içinde kaldıkça yeni kayıt oluşmaz. Ayırt etmek için toplayıcının bağlantı durumunu ayrı bir tag olarak yayımlaması, periyodik bir canlılık (heartbeat) sinyalinin okunması veya Sparkplug B gibi durum bildirimli bir protokolün kullanılması gerekir.