Kualitas Data Sensor Harus Terlihat di Dashboard

Kualitas data sensor seharusnya terlihat bersama setiap angka di dashboard. Nilai yang tampak wajar belum tentu sudah melewati pemeriksaan kualitas, sedangkan nilai yang melewati batas alarm belum tentu berasal dari sensor yang bermasalah.

Karena itu, dashboard perlu memisahkan tiga informasi: nilai pengukuran, status hasil uji quality control (QC), dan kondisi alarm operasional. Pemisahan ini membantu operator memilih apakah sebuah record dapat digunakan, perlu ditinjau, harus ditandai gagal, atau memang tidak tersedia.

Kualitas data sensor bukan status alarm

Nilai pengukuran menjawab pertanyaan “berapa hasil yang dibaca?”. Quality flag menjawab “apa hasil pemeriksaan QC terhadap record ini?”. Alarm menjawab pertanyaan lain: “apakah nilai melewati batas operasional yang telah dikonfigurasi?”

Ketiganya dapat menghasilkan kombinasi yang berbeda. Nilai dapat berada di bawah batas alarm tetapi tetap meragukan karena timestamp tidak sesuai, data berhenti berubah, atau terjadi lonjakan yang tidak konsisten dengan pola di sekitarnya. Sebaliknya, nilai ekstrem dapat melewati alarm dan tetap merepresentasikan kejadian nyata yang perlu diperiksa, bukan langsung dihapus.

Halaman Air Quality Monitoring System (AQMS) Fortuna Argatech memverifikasi konteks dashboard real-time, pengelolaan threshold, dan notifikasi. Halaman publik tersebut tidak mendokumentasikan skema quality flag tertentu. Jika status kualitas dibutuhkan, field, pengujian, dan aturan tindak lanjutnya harus dipastikan saat desain atau konfigurasi solusi.

Simpan status minimum yang dapat ditindaklanjuti

Manual QARTOD untuk quality flag data oseanografi real-time menyediakan satu model primer yang mudah dipahami manusia maupun proses otomatis. Skema itu menggunakan lima keadaan. Ini bukan kewajiban universal atau regulasi Indonesia, tetapi dapat menjadi referensi saat tim mendefinisikan status internal.

Status referensi	Arti yang aman digunakan	Pertanyaan tindak lanjut
1 Pass	Record melewati uji QC real-time kritis yang dikonfigurasi dan dapat diperlakukan sebagai data awal sesuai tujuan yang disetujui	Proses atau laporan mana yang boleh menggunakan data awal ini?
2 Not evaluated	Record belum dievaluasi atau statusnya belum diketahui	Apakah data harus ditahan sampai pemeriksaan tersedia?
3 Suspect	Record membutuhkan perhatian atau memiliki karakter yang menarik untuk ditinjau	Bukti lapangan, data sekitar, atau riwayat sensor apa yang perlu diperiksa?
4 Fail	Record gagal uji yang berlaku dan harus ditandai jelas bila tetap disebarkan	Proses otomatis mana yang harus menolak atau memisahkannya?
9 Missing	Observasi tidak tersedia dan kekosongan dicatat secara eksplisit	Apakah sistem menampilkan gap tanpa menggantinya dengan nol atau nilai terakhir?

Status Pass tidak berarti data terbukti akurat untuk semua kebutuhan, setara hasil laboratorium, atau memenuhi setiap kewajiban pelaporan. Artinya terbatas: record melewati uji yang memang dijalankan. Kesesuaian akhir tetap bergantung pada tujuan penggunaan, QA plan, kalibrasi, pemeliharaan, serta review lanjutan.

Pilih uji otomatis dari risiko data

Daftar uji yang panjang tidak otomatis membuat data lebih dapat dipercaya. Pilih pengujian dari perilaku parameter, kondisi lokasi, interval pencatatan, sumber referensi, tujuan data, dan konsekuensi jika record yang salah digunakan.

Manual QARTOD untuk observasi pH mendokumentasikan keluarga uji seperti gap, syntax, gross range, spike, rate of change, flat line, multivariate, dan neighbor check. Beberapa di antaranya dapat memberi kerangka berpikir untuk parameter lain, tetapi batas dan kombinasi ujinya tidak boleh disalin tanpa evaluasi.

Uji range, misalnya, dapat menyaring nilai yang secara fisik atau teknis tidak masuk akal. Ia belum cukup untuk menemukan sensor yang berhenti pada satu angka, perubahan terlalu cepat, record terlambat, atau pola yang bertentangan dengan parameter terkait. Setiap uji juga perlu menyimpan versi konfigurasi dan alasan flag agar hasilnya dapat ditelusuri.

Jangan buang nilai ekstrem sebelum konteks diperiksa

Menghapus outlier secara diam-diam dapat menghilangkan informasi dan membuat record yang ditolak terlihat seperti gangguan komunikasi biasa. Pendekatan yang lebih aman adalah mempertahankan observasi mentah, menambahkan status primer, lalu menyimpan alasan dari uji yang memicu flag.

Status Suspect penting karena nilai yang tidak biasa belum tentu salah. Perubahan lingkungan yang nyata dapat menyerupai anomali instrumen. Review dapat membandingkan record sebelum dan sesudahnya, sensor atau parameter pendamping, catatan perawatan, kondisi lapangan, dan metode referensi yang tersedia.

Jika perbedaan muncul antara sistem online dan pengujian laboratorium, gunakan alur diagnosis yang sesuai pada artikel hasil sensor online dan laboratorium. Jangan mengubah salah satu hasil hanya agar keduanya tampak sama.

Bawa status dan alasannya sampai ke dashboard

Quality flag hanya berguna jika tetap terhubung dengan observasi. Model data OGC SensorThings API Part 1: Sensing 1.1 menunjukkan bahwa sebuah observation dapat membawa resultQuality, validTime, resultTime, dan parameter kontekstual. Ini menunjukkan kemungkinan pemodelan, bukan bukti bahwa platform tertentu otomatis menggunakan standar tersebut.

Untuk kebutuhan dashboard, record minimum sebaiknya memungkinkan tim menemukan nilai dan satuannya, waktu observasi dan waktu pemrosesan, identitas sensor atau channel, status kualitas primer, alasan atau hasil uji, serta versi aturan yang digunakan. Field persisnya dapat berbeda menurut database dan integrasi.

Dashboard tidak perlu menampilkan seluruh detail diagnostik di layar utama. Status primer dapat menjadi ringkasan, sedangkan panel detail atau riwayat audit menyimpan uji mana yang gagal dan konfigurasi yang berlaku. Dengan begitu, operator memperoleh jawaban singkat tanpa kehilangan jejak teknis.

Tetapkan tindakan untuk setiap status sebelum go-live

Status tanpa aturan tindakan hanya memindahkan kebingungan ke layar. Sebelum sistem digunakan, tentukan setidaknya empat hal:

1. Proses, laporan, atau alarm mana yang boleh menggunakan setiap status.
2. Siapa yang menerima record Suspect atau Fail untuk ditinjau.
3. Bukti apa yang diperlukan untuk mengubah status, mengoreksi data turunan, atau menutup review.
4. Bagaimana record mentah, perubahan status, pengguna, waktu, dan alasan keputusan tetap dapat ditelusuri.

Aturan tersebut perlu diuji menggunakan pola data yang mewakili operasi normal, data hilang, perubahan cepat, record yang berhenti, dan kejadian ekstrem yang mungkin nyata. Pengujian status kualitas dapat dimasukkan ke pemeriksaan integrasi dan commissioning, bersama validasi timestamp, jaringan, penyimpanan lokal, dashboard, dan notifikasi.

Interval juga memengaruhi kemampuan uji gap, spike, dan rate of change. Artikel memilih interval data logger membahas pemisahan waktu baca, simpan, dan kirim tanpa menganggap satu interval sesuai untuk semua sistem.

Review kebutuhan data sebelum mengubah dashboard

Mulailah dari keputusan yang akan dibuat menggunakan data, bukan dari warna status atau daftar uji. Bawa tujuan penggunaan, parameter dan dinamika lokasi, metode referensi, riwayat pemeliharaan, interval data, batas alarm, toleransi ketidakpastian, serta pembagian tanggung jawab review.

Fortuna Argatech menangani custom engineering, telemetry, remote monitoring, dan integrasi dashboard. Kebutuhan quality flag perlu dikaji sebagai persyaratan solusi dan diverifikasi terhadap arsitektur serta dokumentasi proyek yang disetujui; artikel ini tidak menyatakan bahwa satu skema sudah tersedia pada seluruh implementasi. Untuk membahas kebutuhan data dan batas integrasinya, hubungi tim Fortuna Argatech.