Arsitektur Digital Twin Murah untuk Utilitas Air Kecil: Menghormati Batas, Bukan Mengabaikannya

Pembaruan 31 Juli 2026. Arsitektur yang dijelaskan di bawah ini bertumpu pada dua komponen Cloudflare yang kini tidak bisa lagi saya rekomendasikan: Cloudflare D1 sudah saya hentikan pemakaiannya permanen per 5 Mei 2026 (digantikan NATS JetStream sebagai tulang punggung sinkronisasi data lintas-perangkat), dan eksperimen sejak tulisan ini terbit menunjukkan bahwa Cloudflare Workers secara struktural tidak bisa menjangkau jaringan OT tempat data SCADA berada (tanpa konektivitas VPC/private network, data harus di-push dari dalam, bukan di-pull dari edge). Revisi arah arsitektur ini sedang saya kerjakan di epanet.fdiskandar.com ; inti dari pendekatan yang dikoreksi tetap sama (EPANET via WebAssembly, tanpa server on-premise mahal, tanpa lisensi vendor), namun backend-nya kini berjalan di Node.js biasa yang terhubung ke SCADA historian lewat transport pesan, bukan di Workers yang terisolasi dari OT. Bagian tentang batas memori, skeletonization, dan pilihan formula hidraulik di bawah ini tetap relevan dan saya biarkan utuh. Bagian yang membahas D1 dan asumsi Workers-sebagai- penerima-data-SCADA sudah tidak akurat; saya biarkan sebagai catatan eksplorasi historis agar pembaca bisa mengikuti jejak penalaran dan koreksinya.

Catatan pembaca. Ini catatan eksplorasi teknis, bagian dari eksperimen pribadi menguji seberapa jauh arsitektur serverless bisa dipakai untuk simulasi hidrolik berbiaya rendah. Ia ditulis untuk pembaca teknis, belum teruji di produksi skala penuh, dan sebaiknya dibaca sebagai peta rancangan yang mengundang koreksi, bukan resep jadi. Konteks organisasi yang membuat teknologi seperti ini berhasil atau gagal saya tulis terpisah di analisis transformasi digital utilitas air , dan kontras antara demo yang meyakinkan secara visual dengan sistem yang benar-benar dikalibrasi saya bedah di Digital Twin Bisa Dibangun dalam Sehari, Kepercayaan Terhadapnya Tidak . Tulisan ini adalah bagian yang lebih teknis dari benang yang sama: bukan lagi soal membedakan kilau dari substansi, melainkan resep konkret membangun substansi itu.

Utilitas air skala kecil di Indonesia biasanya terjebak di antara dua pilihan yang sama-sama tidak nyaman. Pilihan pertama: sistem SCADA (Supervisory Control and Data Acquisition) dan perangkat lunak pemodelan hidrolik konvensional, yang menuntut server on-premise, lisensi mahal, dan tenaga TI berdedikasi yang jarang dimiliki PDAM kecil. Pilihan kedua: tidak punya simulator hidrolik sama sekali, mengelola jaringan pipa dari intuisi dan pengalaman lapangan, tanpa alat bantu untuk menguji skenario sebelum keputusan diambil.

Saya penasaran apakah ada jalan ketiga, dan menghabiskan waktu senggang membedah satu kemungkinan: memindahkan mesin simulasi hidrolik ke arsitektur serverless modern, memanfaatkan Cloudflare Workers untuk komputasi, D1 untuk basis data, dan Queues untuk menahan lonjakan data sensor. Bukan sekadar alternatif “murah”, melainkan pemindahan beban komputasi dari server pusat ke tepi jaringan internet, sesuatu yang secara arsitektural berbeda dari cara SCADA konvensional dirancang.

Tulisan ini membedah rancangan itu, dan yang lebih penting, batas-batas fisiknya. Sebab murah dan terlihat berfungsi itu gampang dicapai. Murah dan benar-benar bisa dipercaya menuntut disiplin desain yang berbeda.

Kenapa bukan SCADA konvensional saja

Sebelum masuk ke arsitekturnya, ada pertanyaan yang layak dijawab jujur: kalau SCADA konvensional sudah terbukti puluhan tahun, kenapa repot mencari alternatif?

Jawabannya bukan karena SCADA buruk. Sistem itu terbukti andal justru karena dirancang untuk lingkungan yang stabil dan dedicated: perangkat keras khusus, jaringan tertutup, staf yang terlatih menjaganya. Yang tidak cocok dengan PDAM kecil adalah prasyaratnya, bukan kemampuannya. Lisensi perangkat lunak pemodelan hidrolik komersial umumnya dihitung per pengguna atau per node jaringan, dan angkanya cepat membengkak begitu jaringan tumbuh. Server on-premise butuh ruang, pendingin, dan seseorang yang bertanggung jawab menjaganya tetap hidup, sesuatu yang jarang jadi prioritas anggaran di PDAM dengan pendapatan pas-pasan.

Arsitektur serverless tidak menggantikan SCADA untuk kendali waktu-nyata jaringan kritis skala besar, itu bukan domainnya. Yang ditawarkannya adalah jalan masuk bagi utilitas yang belum punya kemampuan simulasi hidrolik sama sekali, dengan biaya di muka mendekati nol dan biaya operasional yang mengikuti pemakaian aktual, bukan lisensi tahunan flat. Trade-off-nya, seperti akan terlihat di bagian berikut, adalah menerima batas infrastruktur yang jauh lebih ketat daripada server dedicated.

Memindahkan mesin simulasi ke WebAssembly

Jantung dari sistem seperti ini adalah algoritma penyelesaian jaringan pipa. Standar industri globalnya adalah EPANET, yang dikembangkan Badan Perlindungan Lingkungan Amerika Serikat (EPA) dan sudah dipakai luas untuk memodelkan aliran dan kehilangan tekanan (head loss) di jaringan pipa [1].

Cloudflare Workers adalah lingkungan eksekusi JavaScript berbasis mesin V8. Menjalankan perhitungan matriks yang kompleks secara native di JavaScript adalah strategi yang lambat dan rawan timeout. Jalan yang lebih masuk akal adalah memindahkan mesin EPANET, yang aslinya ditulis dalam C, ke WebAssembly (WASM), format biner yang bisa dieksekusi mendekati kecepatan native di dalam browser atau serverless worker. Proyek epanet-js sudah melakukan porting persis ini: port penuh dari toolkit resmi OWA-EPANET ke WebAssembly, berlisensi MIT, dipakai untuk membangun aplikasi analisis hidrolik langsung di browser maupun server [2].

Batas memori yang harus dihormati sejak desain awal

Di sinilah batas fisik pertama muncul. Cloudflare Workers membatasi memori 128 MB per isolate, mencakup heap JavaScript dan alokasi WebAssembly sekaligus [3]. Model hidrolik yang memuat ribuan simpul (node) dan pipa, kalau tidak dikelola hati-hati, bisa memicu alokasi memori WASM yang melampaui batas ini dan membuat isolate dihentikan paksa.

Tiga strategi mitigasi yang menurut saya masuk akal:

1. Skeletonization. Sederhanakan topologi jaringan sebelum dimuat ke solver. Pipa kecil berdiameter di bawah 50 mm yang melayani sambungan rumah individu jarang memberi dampak hidrolik signifikan, tapi membebani memori matriks solver secara tidak proporsional terhadap manfaatnya.
2. Batas memori eksplisit saat kompilasi. Tetapkan batas atas yang aman untuk alokasi WASM, menyisakan ruang untuk runtime JavaScript di sekitarnya.
3. Pemrosesan bertahap. Muat berkas input jaringan (.inp) secara streaming atau parsial, bukan sekaligus penuh ke memori.

Formula yang dipilih ikut menentukan akurasi

Aspek fisik lain yang gampang diabaikan adalah kurva pompa. Model sederhana sering memakai kurva pompa satu titik, padahal performa pompa di lapangan berubah dinamis mengikuti hukum afinitas ketika kecepatan putarnya diatur variable speed drive. Sistem yang layak dipercaya perlu memodelkan kurva pompa lewat regresi polinomial, bukan angka tunggal.

Pilihan formula gesekan juga bukan keputusan netral. Hazen-Williams jauh lebih murah dihitung, dan itu daya tariknya untuk arsitektur serverless yang dibatasi waktu CPU. Tapi ia kurang akurat dibanding Darcy-Weisbach terutama untuk pipa besar atau kecepatan aliran tinggi, karena koefisiennya menyatukan kekasaran pipa dan efek bilangan Reynolds jadi satu angka tunggal yang sebetulnya berubah seiring kecepatan aliran [4]. Untuk jaringan air bersih skala PDAM kecil dengan kecepatan aliran moderat, Hazen-Williams biasanya cukup. Untuk jaringan dengan pipa besar atau tekanan tinggi, kompromi ini perlu ditinjau ulang, bukan diterima begitu saja karena lebih ringan dihitung.

Menjinakkan lonjakan data dari ribuan sensor

Tantangan terbesar sistem IoT semacam ini bukan pada satu sensor, melainkan pada perilaku kolektif ribuan sensor sekaligus. D1, basis data Cloudflare yang berbasis SQLite, secara inheren memproses query satu per satu per basis data [5]. Kalau lima ratus sensor mencoba menulis bersamaan ke tabel yang sama, sebagian besar permintaan akan antre atau gagal.

Solusinya adalah memisahkan proses penerimaan data dari proses penyimpanannya, memakai Cloudflare Queues sebagai penyangga elastis [6]:

1. Worker penerima (producer). Titik masuk API yang sangat ringan: validasi token, kirim pesan ke antrean. Tidak ada penulisan basis data di sini, jadi tidak ada risiko lock.
2. Antrean Cloudflare Queues. Penampung sementara yang elastis dan tahan gangguan.
3. Worker pemroses (consumer). Dipicu antrean secara batch, misalnya seratus pesan sekaligus, lalu menulis semuanya dalam satu transaksi SQL (Batch INSERT) ke D1.

Pola ini menekan biaya operasi D1 secara drastis dan menghindari batas konkurensi yang tadi disebut. Sebelum data ditulis, filter stokastik sederhana juga layak diterapkan di worker pemroses: rata-rata bergerak (moving average) untuk menghaluskan fluktuasi tekanan, dan penolakan pencilan (outlier rejection) untuk membuang data yang jelas keliru secara statistik.

Basis data yang fleksibel tapi tetap cepat dicari

Salah satu fitur D1 yang menurut saya kurang dimanfaatkan adalah kolom hasil-turunan (generated columns). Data sensor bisa disimpan sebagai JSON mentah, fleksibel seperti basis data dokumen, tapi tetap bisa dicari secepat kolom SQL biasa:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

CREATE TABLE telemetry (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  sensor_id TEXT NOT NULL,
  timestamp INTEGER NOT NULL,
  raw_payload TEXT, -- JSON: {"pressure": 3.5, "flow": 10.2}
  pressure REAL GENERATED ALWAYS AS (json_extract(raw_payload, '$.pressure')) VIRTUAL,
  flow REAL GENERATED ALWAYS AS (json_extract(raw_payload, '$.flow')) VIRTUAL
);

CREATE INDEX idx_telemetry_pressure ON telemetry(pressure);

Dengan desain ini, pencarian WHERE pressure < 1.0 memakai indeks kolom virtual yang cepat, jauh lebih efisien daripada memindai teks JSON satu per satu.

Untuk retensi datanya, saya membayangkan tiga lapis: data hangat (30 sampai 60 hari terakhir) disimpan langsung di D1 untuk kueri cepat, data dingin dipindahkan ke Cloudflare R2 sebagai berkas CSV atau Parquet yang murah dan tahan lama, dan data lama dibersihkan dari D1 secara terjadwal supaya performanya tetap terjaga.

Menampilkannya tanpa membangun sistem login sendiri

Untuk sisi tampilan, Hugo bisa membangun kerangka aplikasi statis (app shell) saat proses build, memuat pustaka peta seperti Leaflet atau MapLibre. Saat berjalan di browser, JavaScript sisi klien mengambil data dinamis dari Workers, lalu “menghidrasi” peta itu, misalnya mengubah warna pipa sesuai tekanan terkini.

Untuk otentikasinya, saya lebih memilih tidak membangun sistem login sendiri. Cloudflare Access, bagian dari produk Zero Trust mereka, bisa melindungi dasbor di belakang otentikasi email korporat tanpa Worker perlu mengelola basis data pengguna dan kata sandi sendiri [7]. Cloudflare menyisipkan token JWT yang tinggal divalidasi Worker.

Ringkasan trade-off untuk yang menimbang pilihan ini

Tabel 1. Tiga keputusan arsitektur utama dan apa yang dikorbankan di tiap pilihannya.

Tidak satu pun baris di tabel itu punya jawaban benar universal. Yang benar tergantung ukuran jaringan, anggaran, dan seberapa presisi keputusan operasional yang akan digantungkan pada hasil simulasinya.

Satu langkah konkret

Ini satu langkah yang bisa dimulai besok kalau arsitektur ini terasa relevan: jangan langsung membangun untuk seluruh jaringan. Ambil satu zona kecil, di bawah dua ratus simpul, bangun pipeline-nya penuh (WASM, Queues, D1, tampilan), lalu ukur biaya operasional aktualnya selama sebulan penuh sebelum memutuskan skala lebih besar.

Batas 128 MB dan batas satu-tulis-per-waktu bukan angka abstrak yang cukup dibaca sekali dari dokumentasi. Keduanya baru terasa nyata ketika jaringan yang dimodelkan benar-benar berukuran seperti jaringan sungguhan, bukan contoh kecil di lingkungan pengembangan. Zona kecil memberi ruang untuk menabrak batas itu dengan taruhan yang masih murah, sebelum komitmen ke skala penuh.

Strategi ini menawarkan jalan yang realistis bagi PDAM kecil untuk memiliki simulator hidrolik tanpa investasi server yang berat di muka. Tapi realistis di sini bukan berarti tanpa batas. WASM mengatasi keterbatasan komputasi, Queues mengatasi kemacetan data, D1 dengan kolom virtual memberi kecepatan akses yang dibutuhkan, dan pemilihan formula hidraulik yang sadar akan trade-off-nya memastikan angka yang keluar dari sistem ini memang layak dipercaya, bukan sekadar terlihat berjalan.

Disclaimer: Tulisan ini adalah pandangan pribadi penulis dan tidak mewakili pandangan organisasi mana pun. Informasi yang disajikan bersifat edukatif dan tidak dimaksudkan sebagai nasihat profesional; implementasi teknis harus disesuaikan dengan kondisi spesifik masing-masing utilitas.

Referensi

1. US Environmental Protection Agency, "EPANET." https://www.epa.gov/water-research/epanet
2. epanet-js, "epanet-js-toolkit." GitHub. https://github.com/epanet-js/epanet-js-toolkit
3. Cloudflare, "Limits · Cloudflare Workers docs." https://developers.cloudflare.com/workers/platform/limits
4. ASPE Pipeline, "Hazen-Williams and Darcy-Weisbach Equations: Similarities and Differences." https://aspe.org/pipeline/hazen-williams-and-darcy-weisbach-equations-similarities-and-differences
5. Cloudflare, "Limits · Cloudflare D1 docs." https://developers.cloudflare.com/d1/platform/limits
6. Cloudflare, "Queues." https://developers.cloudflare.com/queues
7. Cloudflare, "Access policies · Cloudflare Zero Trust docs." https://developers.cloudflare.com/cloudflare-one/policies/access/