Ditulis oleh Ketut Kumajaya | 28 September 2025

Pengantar

Dalam sistem DCS/SCADA, drift data akumulasi adalah masalah klasik. Counter runtime, hour meter, atau energi meter sering mengalami penyimpangan akibat overflow tipe data, jitter komunikasi, atau perbedaan jam antar perangkat. Bias kecil yang dibiarkan akan menumpuk, menghasilkan data historis yang tidak konsisten dan menyimpang.

Contoh sederhana: akumulasi flowmeter menyimpang hingga 2% dari nilai seharusnya, tanpa ada yang menyadari.

Untuk mengatasi hal ini, artikel ini memperkenalkan pendekatan Anchor-Based Normalization: strategi koreksi berbasis satu titik referensi (anchor point) yang ditanam di DCS, dengan Rapid SCADA sebagai time authority dan Node-RED sebagai relay REST API yang melakukan koreksi on-demand.

Lebih dari sekadar normalisasi, pendekatan ini mewujudkan self-healing measurement pipeline, di mana sistem secara otomatis mendeteksi deviasi, menerapkan koreksi hanya saat diperlukan, dan menyimpan catatan audit secara transparan.

Konsep Anchor-Based Normalization

  • Anchor Point → nilai referensi tunggal yang diketahui benar (misalnya input statis flowrate = 3750).
  • Window Historis → data 4–24 jam terakhir dari Rapid SCADA digunakan untuk menghitung selisih (offset).
  • Offset Correction → selisih antara anchor dan histori diterapkan ke semua accumulator.
  • Normalization → setiap data yang diminta ERP atau sistem bisnis lain sudah terkoreksi, sementara data mentah tetap tersimpan di Rapid SCADA.

Dengan cara ini, cukup satu anchor point untuk meluruskan seluruh accumulator.

Zona Deviasi

Untuk menjaga keseimbangan antara presisi dan keandalan, digunakan logika tiga zona:

Zona Kriteria Deviasi Relatif Status Koreksi Catatan Audit
Hijau ≤ stddev Tidak diterapkan (applied: false) Deviasi dianggap noise, data dilewatkan apa adanya
Kuning > stddev dan ≤ max Diterapkan (applied: true) Koreksi normal, offset dicatat di header
Merah > max Tidak diterapkan (applied: false) Data dianggap outlier, dilewatkan as-is dengan flag audit

Contoh kasus: deviasi 0.1% masuk zona hijau sehingga tidak dikoreksi, deviasi 0.35% masuk zona kuning sehingga koreksi diterapkan, sedangkan deviasi 12.5% masuk zona merah sehingga data dilewatkan apa adanya dengan catatan audit.

Contoh Numerik Anchor-Based Normalization

  • Anchor Point (DCS): flowrate = 3750
  • Window Historis (SCADA 4 jam terakhir): rata-rata akumulator terbaca 3737
  • Offset:
    $$\text{Offset} = \frac{3737 - 3750}{3750} \times 100% = -0.35%$$

Offset negatif di sini artinya histori terbaca lebih rendah dibanding anchor.

Evaluasi Zona Deviasi

  • Threshold stddev: 0.20%
  • Threshold max: 5.0%

Maka:

  • Deviasi relatif = 0.35%
  • Karena 0.20% < 0.35% ≤ 5.0%, maka masuk Zona Kuning.
  • Status: applied = true → koreksi offset diterapkan.

Payload Hasil Koreksi

"correction": {
  "applied": true,
  "relative_deviation": 0.35,
  "std_dev_threshold": 0.20,
  "max_threshold": 5.0
}

ERP atau sistem bisnis cukup membaca bagian data[] dengan tenang, karena hasil sudah terjamin sesuai header correction.

Perbandingan Kasus Lain

  • Deviasi 0.1% → ≤ 0.20% → Zona Hijau → tidak dikoreksi (applied: false).
  • Deviasi 0.35% → antara 0.20% dan 5.0% → Zona Kuning → dikoreksi (applied: true).
  • Deviasi 12.5% → > 5.0% → Zona Merah → tidak dikoreksi, dilewatkan as-is dengan catatan audit.

Implementasi Payload

Informasi koreksi cukup ditaruh sekali di header. Data di bawah tetap bersih, hanya menampilkan nilai akumulator.

{
  "site": "SIG025",
  "description": "SIG Bekasi",
  "correction": {
    "applied": true,
    "relative_deviation": 0.35,
    "std_dev_threshold": 0.20,
    "max_threshold": 5.0
  },
  "data": [
    {
      "index": 0,
      "code": "FTLOX-01",
      "description": "[1294] LOX Flow Totalizer",
      "source": "[1294] LOX Flow Totalizer",
      "data": [
        {
          "value": 829908.5625,
          "timestamp": "2025-09-28T01:00:00+07:00"
        },
        {
          "value": 826878.5,
          "timestamp": "2025-09-28T00:00:00+07:00"
        },
        {
          "value": 823849.1875,
          "timestamp": "2025-09-27T23:00:00+07:00"
        }
        ...

Visualisasi Alur Data

flowchart TD A["DCS: Akumulator (Flow Totalizer)"] --> B["Rapid SCADA: Simpan raw historis"] B --> C["Node-RED: Ambil raw saat ERP request"] C --> D["Bandingkan dengan Anchor"] D --> E{"Zona deviasi?"} E -->|"Hijau (<= stddev)"| F["Applied: false"] E -->|"Kuning (antara stddev dan max)"| G["Applied: true"] E -->|"Merah (> max)"| H["Applied: false"] F --> I["Header correction"] G --> I H --> I I --> J["ERP: Konsumsi payload"]
Alur Anchor-Based Normalization: SCADA tetap menyimpan data mentah, Node-RED memutuskan zona deviasi, dan ERP selalu menerima data yang sudah diputuskan sesuai header koreksi.

Kesimpulan

Dengan Anchor-Based Normalization berbasis anchor point di DCS dan logika tiga zona deviasi, pipeline data menjadi lebih presisi karena drift wajar terkoreksi, lebih aman karena noise kecil diabaikan dan outlier besar dilewatkan, serta lebih transparan karena data mentah tetap utuh sementara catatan koreksi tersimpan jelas.

Pendekatan ini membuat sistem audit-ready, mudah diajarkan lintas operator, dan scalable untuk berbagai aplikasi industri, khususnya pada akumulator seperti flow totalizer.

Hasilnya, audit tidak lagi disibukkan membetulkan angka, melainkan dapat langsung fokus pada analisis operasional dan pemeriksaan lanjutan berbasis catatan koreksi.