PLC verisini SQL’e aktarırken beş tasarım kararı

PLC verisini bir SQL veritabanına yazmak, iyi araçlarla bir öğleden sonrada yapılabilir: bir kaynak, bir hedef, bir akış. Asıl soru, bunun iki yıl sonra da doğru, hızlı ve sorgulanabilir kalıp kalmayacağıdır. Aşağıdaki beş karar, ilk akışı kurmadan önce verilirse sonradan pahalı yeniden yazımlardan kaçınılır. Veriyi taşıyan araç OPC Router veya Kepware Server DataLogger olabilir; kararlar aynıdır.

Karar 1: Ne zaman yazılacak?

• Periyodik: Her N saniyede bir örnek. Trend ve günlük için basittir ama hacim hızla büyür.
• Değişimde: Değer deadband’i aştığında. Hacmi belirgin biçimde düşürür; ancak “veri neden yok?” sorusu için ek bir kalp atışı (periyodik kayıt) gerekebilir.
• Olay veya parti sonunda: Üretim sonucu, sayaç değeri, parti özeti. Raporlar için en temiz seçenektir.

Örnek bir hesap: 500 etiket × saniyede 1 kayıt = günde yaklaşık 43,2 milyon satır. Değişime göre kayıt ve uygun deadband’ler çoğu proseste bu hacmi belirgin biçimde azaltır.

Karar 2: Tablo yapısı

Sürekli ölçümler için dar yapı sağlam bir başlangıçtır. Aşağıdaki örnek yalnızca fikir vermek içindir; söz dizimi veritabanı motoruna göre değişir:

CREATE TABLE tag (
  tag_id      INTEGER PRIMARY KEY,
  path        VARCHAR(200) NOT NULL UNIQUE,  -- OPC öğe yolu
  unit        VARCHAR(20),
  description VARCHAR(200)
);
CREATE TABLE measurement (
  tag_id     INTEGER   NOT NULL REFERENCES tag(tag_id),
  source_ts  TIMESTAMP NOT NULL,             -- UTC, kaynak zaman damgası
  value_num  DOUBLE PRECISION,               -- Bad ise NULL
  quality    SMALLINT  NOT NULL,             -- 0 Good, 1 Uncertain, 2 Bad
  PRIMARY KEY (tag_id, source_ts)
);

Karar 3: Zaman

• UTC saklayın, gösterimde yerele çevirin; yaz saati uygulaması çift veya eksik saat üretmez.
• Kaynak zaman damgasını yazın; sunucunun veya veritabanının yazma anını değil (veri kalitesi ve zaman damgası).
• PLC, sunucu ve veritabanı saatlerini NTP ile senkron tutun.
• (tag_id, source_ts) üzerinde birincil anahtar veya dizin; zaman aralığı sorgularının temelidir.

Karar 4: Kalite ve boş değer

Kalitesi Bad olan bir değeri sıfır olarak yazmayın; gerçek sıfırdan ayırt edilemez. Değeri NULL bırakın ve kalite kodunu kaydedin. Raporlar kaliteye göre süzmeli ya da boşluğu açıkça göstermelidir. Bu, OEE, tüketim veya ortalama hesaplarının doğruluğunun temelidir (OEE için veri hazırlığı).

Karar 5: Hata, hacim ve saklama

• Hata: Veritabanı ulaşılamazsa veri kaybolmamalı; kaynakta tamponlanıp bağlantı gelince yeniden gönderilmelidir (yedeklilik, tamponlama ve kurtarma).
• Yinelenenler: Yeniden gönderim aynı kaydı iki kez üretmemelidir. Birincil anahtar çakışmasını yok sayan veya güncelleyen (upsert) yazma kullanın.
• Toplu yazma: Kayıtları tek tek yerine kısa aralıklarla gruplayıp tek işlemde yazın.
• Saklama: Ham veriyi ne kadar tutacaksınız? Eski veriyi saatlik/günlük özetlere indirgeyip arşivleyin; büyük tablolarda zaman bazlı bölümleme (partition) düşünün.
• Raporlama için ayrı görünümler: Raporlar ham tabloyu doğrudan sorgulamasın; özet tablolar veya görünümler kullanın.

SQL mi, tarihçe mi?

Orta hızlı veri, ilişkisel sorgular ve kurumsal raporlama için SQL uygundur. Çok yüksek hızlı zaman serileri, sıkıştırma ve trend araçları için bir tarihçe (historian) veya zaman serisi veritabanı daha verimli olabilir. İkisi birlikte de kullanılır: ham veri tarihçede, özetler ve olaylar SQL’de. Tüm veri toplama seçenekleri için doğru veri toplama yolunu seçmek yazısına bakın.

Sık sorulan sorular