IoT pada Sistem Orifice Metering: Dari Pembacaan Harian ke Otomasi Data

Kalau saya ingat kembali masa-masa awal pegang Gas Metering System, satu hal yang paling melekat: buku catatan lapangan. Setiap pagi operator keliling ke meter run, membaca differential pressure di manometer, mencatat static pressure dan temperature, lalu pulang ke kantor dan memasukkan angka-angka itu ke spreadsheet. Sore harinya barulah flow dihitung.

Cara kerja itu sudah berjalan puluhan tahun. Dan sejujurnya, sebagian besar waktu saya habis bukan untuk menganalisa data, tapi untuk memindahkan data.

Artikel ini tentang bagaimana IoT mengubah bagian itu — bukan teori besarnya, tapi apa yang benar-benar terjadi di lapangan.

Dasar yang perlu disepakati dulu

Orifice meter mengukur flow secara inferensial. Alat ini tidak mengukur flow secara langsung. Yang diukur adalah:

• Differential pressure (ΔP) — beda tekanan sebelum dan sesudah orifice plate
• Static pressure (Pf) — tekanan absolut di upstream
• Flowing temperature (Tf) — suhu gas yang mengalir

Ketiganya lalu dimasukkan ke persamaan flow sesuai AGA Report No. 3. Di luar tiga variabel itu, masih ada parameter yang harus benar: diameter orifice (d), diameter pipa (D), rasio beta (β = d/D), specific gravity gas, dan faktor kompresibilitas (Z) yang bergantung pada komposisi gas.

Ini penting dipahami sebelum bicara IoT. Sensor yang salah kalibrasi tidak akan menjadi benar hanya karena datanya dikirim ke cloud. Digitalisasi tidak memperbaiki pengukuran — ia hanya mempercepat dan memperbanyak datanya.

Titik lemah cara manual

Dari pengalaman, ada empat masalah yang konsisten muncul:

Pertama, sampling rate terlalu rendah. Satu pembacaan per hari untuk proses yang berubah setiap menit. Kalau ada lonjakan ΔP jam 2 siang dan kembali normal jam 3, catatan harian tidak akan pernah menangkapnya. Yang tercatat hanya rata-rata, dan rata-rata menyembunyikan kejadian.

Kedua, human error. Salah baca skala, salah ketik, kolom tertukar. Bukan karena operatornya lalai, tapi karena pekerjaannya memang monoton dan berulang.

Ketiga, tidak ada timestamp yang bisa dipercaya. Pembacaan jam 06:15 dan jam 07:40 dicatat sebagai “pagi” di dua baris yang sama. Untuk perhitungan totalisasi, ini masalah serius.

Keempat, data terkunci. Angka-angka itu ada di spreadsheet satu orang. Tidak bisa diakses tim lain, tidak bisa dibuat tren, tidak bisa dijadikan dasar keputusan.

Bagaimana sistem bekerja — process flow

Sebelum masuk ke detail komponen, ada baiknya melihat alurnya secara utuh. Diagram berikut menunjukkan perjalanan data dari sensor di meter run sampai ke keputusan operasional.

Tujuh tahap yang dilalui data

1. Sensing. ΔP, Pf, dan Tf diukur di meter run oleh transmitter masing-masing. Di titik ini kualitas data ditentukan — tidak ada tahap berikutnya yang bisa memperbaikinya.
2. Transmisi sinyal. Sinyal analog 4–20 mA dikirim ke transmitter, atau lewat HART di atas loop yang sama bila instrumennya mendukung.
3. Kompensasi AGA 3. Flow computer melakukan perhitungan lengkap: Z-factor dari komposisi gas, faktor discharge (Cd), rasio beta, dan faktor ekspansi (Y). Hasilnya adalah flow terkoreksi ke base condition.
4. Akuisisi Modbus. Edge gateway membaca register dari flow computer, umumnya setiap 1–5 detik. Yang diambil adalah hasil perhitungan, bukan nilai mentah sensor. Timestamp diambil dari sumber, bukan dari waktu data tiba di gateway.
5. Publish MQTT. Data dikirim ke broker dengan QoS 1 agar tidak hilang di tengah jalan. Bila link putus, gateway menyimpan dan mengirim ulang saat pulih.
6. Simpan time-series. Data masuk ke database time-series yang dioptimalkan untuk query rentang waktu, dengan retensi jangka panjang.
7. Otomasi dan keputusan. Di sini alert, rekonsiliasi harian, dan laporan otomatis dijalankan.

Cabang keputusan dari data

Yang membuat system ini berguna bukan penyimpanan datanya, tapi apa yang dipicu oleh data tersebut:

• ΔP turun mendadak sementara Pf normal — indikasi impulse line tersumbat atau blok cairan, bukan aliran yang berhenti. Memicu inspeksi lapangan hari itu juga.
• ΔP mendekati batas bawah span — di bawah 10% span, error relatif membesar dengan cepat. Memicu evaluasi ukuran orifice plate.
• Gap data melebihi kapasitas buffer — data hilang dan tidak bisa direkonstruksi. Periode harus ditandai secara eksplisit, bukan diinterpolasi diam-diam.
• Drift sistematis terhadap flow referensi — deviasi satu arah yang konsisten selama berminggu-minggu menandakan zero shift, bukan noise. Memicu kalibrasi berbasis kondisi.
• Selisih kirim versus terima harian — rekonsiliasi tiap 24 jam saat penyebabnya masih bisa ditelusuri.

Arsitektur yang realistis

Yang saya sarankan bukan mengganti flow computer. Jangan. Flow computer yang sudah terpasang dan terkalibrasi adalah aset yang mahal dan sudah memenuhi standar. Yang perlu ditambahkan adalah lapisan di atasnya.

Lapisan 1 — Akuisisi data

Ambil data dari sumber yang sudah ada. Ada tiga jalur umum:

• Modbus RTU/TCP dari flow computer — jalur paling bersih, karena flow computer sudah menghitung flow terkompensasi. Yang kita ambil adalah hasil akhirnya, bukan menghitung ulang.
• 4–20 mA loop dengan konverter ke Modbus, kalau flow computer tidak punya port komunikasi.
• HART di atas loop 4–20 mA, kalau instrumennya mendukung. Ini memberi akses ke nilai sekunder tanpa mengganggu sinyal utama.

Prioritas pertama: ambil dari flow computer, jangan hitung ulang dari sensor mentah. Menghitung ulang membuka pintu perbedaan hasil dengan angka resmi — dan itu mimpi buruk saat rekonsiliasi.

Lapisan 2 — Edge gateway

Gateway industri di lokasi meter membaca Modbus, memberi timestamp lokal, menyimpan buffer, lalu mengirim ke broker.

Yang wajib ada di gateway:

• Store-and-forward. Jaringan di lokasi remote akan putus. Gateway harus menyimpan data selama putus dan mengirim ulang setelah pulih. Tanpa ini, ada lubang data yang tidak bisa direkonstruksi.
• Timestamp dari sumber, bukan timestamp saat data tiba di server. Selisih beberapa detik saat sinkronisasi bisa menggeser data ke interval yang salah.
• Buffer minimal 7 hari. Cukup untuk menutup gangguan komunikasi yang wajar.

Lapisan 3 — Broker dan penyimpanan

MQTT sebagai protokol transport, karena ringan dan cocok untuk link yang tidak stabil. Database time-series untuk penyimpanan — InfluxDB, TimescaleDB, atau sejenisnya. Bukan database relasional biasa, karena pola query-nya adalah “semua nilai antara jam X dan jam Y”, dan itu yang paling tidak efisien di database relasional.

Lapisan 4 — Visualisasi dan otomasi

Dashboard untuk monitoring, dan di sinilah nilai sesungguhnya muncul: alert, rekonsiliasi otomatis, dan pelaporan.

Yang berubah setelah terpasang

Ini bagian yang paling terasa, dan biasanya tidak terduga.

Deteksi anomali jadi mungkin. ΔP yang tiba-tiba turun ke nol padahal static pressure normal — itu indikasi impulse line tersumbat, bukan flow berhenti. Tanpa data kontinu, kejadian seperti ini lewat begitu saja dan baru ketahuan saat rekonsiliasi bulanan selisih.

Kalibrasi jadi berbasis kondisi, bukan jadwal. Kalau drift instrumen bisa dilihat dari tren, kalibrasi bisa dijadwalkan saat dibutuhkan, bukan setiap enam bulan untuk semua instrumen tanpa kecuali.

Rekonsiliasi harian, bukan bulanan. Ini yang paling saya hargai. Selisih antara gas yang dikirim dan gas yang diterima biasanya baru ketahuan di akhir bulan, saat sudah terlambat untuk mencari penyebabnya. Dengan data harian, selisih ketahuan dalam 24 jam, saat konteksnya masih segar.

Laporan terbentuk sendiri. Tidak ada lagi dua hari kerja di akhir bulan untuk menyusun rekap.

Yang harus diwaspadai

Saya tidak akan menjual ini sebagai solusi tanpa risiko. Beberapa hal yang perlu diantisipasi:

Keamanan bukan opsional. Perangkat yang terhubung ke internet di instalasi gas adalah permukaan serangan. Minimal: segmentasi jaringan, jangan pernah expose Modbus langsung ke internet, gunakan VPN atau broker dengan TLS, dan pisahkan jaringan OT dari IT. Gateway yang bisa menulis ke PLC harus dibatasi — monitoring cukup read-only.

Akurasi rekening tetap mengacu ke flow computer. Data IoT untuk monitoring dan analisa. Kecuali sistemnya dirancang dan diaudit sebagai sistem custody transfer, angka di dashboard bukan dasar penagihan. Ini harus jelas sejak awal, supaya tidak ada salah paham di kemudian hari.

Jangan hitung ulang flow di cloud. Seperti sudah disinggung di atas — ambil hasil dari flow computer. Kalau terpaksa menghitung, hasilnya harus bisa direkonsiliasi dengan angka resmi, dan perbedaan harus bisa dijelaskan.

Perawatan perangkat itu nyata. Baterai, SIM card, koneksi, firmware. Perangkat yang dipasang lalu dilupakan akan mati dalam dua tahun.

Penutup

Yang membuat IoT menarik di orifice metering bukan teknologinya. Sensor tetap sensor, persamaan tetap AGA 3. Yang berubah adalah jarak antara kejadian dan pengetahuan.

Dulu: kejadian terjadi hari ini, diketahui bulan depan.

Sekarang: kejadian terjadi hari ini, diketahui hari ini.

Untuk pekerjaan yang bergantung pada ketepatan angka, jarak itu bukan kemewahan. Ia adalah selisih antara menemukan masalah dan hanya mencatat akibatnya.