Bir raporda “Reaktör sıcaklığı: 72,4 °C” görüyorsunuz. Ama bu değer şu an mı ölçüldü, yoksa sensör üç saat önce kopmuş ve sistem son geçerli değeri mi gösteriyor? Değer doğru bir ölçüm mü, yoksa bir varsayılan mı? Kalite ve zaman damgası bu sorulara yanıt verir; ikisi olmadan değer güvenilmez bir sayıdır.
OPC UA’da bir veri noktası yalnızca değer değildir: değer + kaynak zaman damgası + sunucu zaman damgası + durum kodu (kalite). Raporlama ve entegrasyon, bu dördünü birlikte taşımalıdır.
Veri noktasının yapısı
Kalite: Good, Uncertain, Bad
OPC UA durum kodunun ciddiyet bitleri verinin güvenilirliğini üç sınıfa ayırır:
| Sınıf | Anlamı | Örnek durumlar | Rapor davranışı |
|---|---|---|---|
| Good | Değer güvenilir | Normal ölçüm; yerel geçersiz kılma (local override) | Normal kullanın |
| Uncertain | Değer kullanılabilir ama şüpheli | Son geçerli değer; yedek değer; sensör hassasiyeti düşük | İşaretleyin, hesaplarda dikkatli olun |
| Bad | Değer güvenilmez | İletişim yok, cihaz veya sensör arızası, yapılandırma hatası | Hesaba katmayın; boşluk olarak gösterin |
Bu sınıfların altında ayrıntılı kodlar (ör. Bad_NotConnected, Bad_SensorFailure, Uncertain_LastUsableValue) bulunur; hata teşhisinde bu kodlar yol gösterir.
Zaman damgası: iki ayrı zaman
- Kaynak zaman damgası (SourceTimestamp): değerin kaynakta (cihazda veya sürücüde) üretildiği an.
- Sunucu zaman damgası (ServerTimestamp): sunucunun değeri aldığı an.
İkisi arasındaki fark gecikmeyi ve bayat veriyi gösterir. Dikkat edilecek noktalar:
- Zamanı kim damgalıyor? Cihaz kendi zamanını veriyorsa kaynak zamanı olaya yakındır. Cihaz zaman damgası sağlamıyorsa sürücü okuma anını damgalar; bu, olay zamanı değil okuma zamanıdır. Olay sıralaması (SOE) gerekiyorsa zaman damgalı olay üreten cihazlar kullanın.
- Saatler senkron mu? NTP (veya hassas uygulamalarda PTP) olmadan farklı cihazların zamanları birbirine güvenle kıyaslanamaz.
- Saat dilimi ve yaz saati: Zamanı UTC olarak saklayın; gösterimde yerel saate çevirin.
- Örnekleme aralığı: Tarama (scan) hızı zaman çözünürlüğünü sınırlar; saniyede bir okunan bir değer milisaniye hassasiyetli olay anlamına gelmez.
SQL ve raporlarda kaliteyi nasıl korumalı?
- Her kayıt için değerle birlikte kalite ve kaynak zaman damgasını saklayın (PLC verisini SQL’e aktarma).
- Bad değeri sıfır olarak yazmayın. Sıfır geçerli bir ölçümdür; hatalı veriyi gerçek sıfırdan ayırt edilemez kılar. Boş (NULL) bırakın ve kaliteyi kaydedin.
- Bayat veriyi tespit edin:
şimdi − kaynak_zamanıeşiği aşarsa değeri bayat işaretleyin. - Hesaplarda (OEE, tüketim, ortalama) yalnızca Good kayıtları kullanın veya boşluğu açıkça yönetin (OEE için veri hazırlığı).
- Dönüşümlerde (OPC UA → MQTT/SQL) kalite ve zaman damgasını düşürmeyin; aksi halde kaynağın verdiği bilgi yolda kaybolur.
Kabul testinde ne doğrulanmalı?
- Bir kabloyu çıkarıp kalitenin Bad’e dönüp dönmediği ve raporların bunu gösterip göstermediği.
- Kaynak ve sunucu zamanı arasındaki farkın makul olması.
- Bağlantı geri geldiğinde değerlerin doğru kaliteyle yeniden akması.
Bu kontroller entegrasyon kabul testi listesine eklenebilir. OPC UA’nın temelleri için OPC UA nedir? yazısına bakın.
Sık sorulan sorular
Uncertain kaliteli veriyi kullanabilir miyim?
Duruma bağlıdır. Örneğin “son geçerli değer” kısa kesintilerde yaklaşık bir gösterge olabilir, ama faturalama veya kalite kararı gibi kritik hesaplarda kullanmamak daha güvenlidir. Her kullanım için kural yazın.
Kaynak ve sunucu zamanı neden farklı olur?
Gecikme, tarama aralığı, saat farkı veya cihazın kendi zamanını vermemesi nedeniyle. Fark büyüyorsa bağlantıyı ve saat senkronizasyonunu inceleyin.
Kalite bilgisi MQTT’ye geçince kaybolur mu?
Dönüşümde alanlar eşlenmezse evet. Sparkplug B gibi bir şema veya kendi JSON şemanız kalite ve zaman damgası alanlarını içermelidir.
