Skip to main content
v1.0

LeakGuard — Hệ thống phát hiện và quản lý rò rỉ nước trong mạng cung cấp nước

Tóm tắt

LeakGuard là nền tảng AI-driven cho phép các cơ quan quản lý nước municipally theo dõi và phát hiện rò rỉ trong mạng cung cấp nước trong thời gian thực, giảm thiệt hại kinh tế và cải thiện hiệu quả sử dụng nguồn nước. Hệ thống kết hợp cảm biến áp lực, dòng lượng và mô hình học máy để xác định các điểm rò rỉ với độ chính xác hơn 90% và giảm thời gian phát hiện từ tuần xuống còn giờ.


Định nghĩa vấn đề

Phát biểu vấn đề

Trong hệ thống cung cấp nước của Việt Nam, các mạng ống có tỷ lệ rò rỉ trung bình 30%, dẫn đến mất khoảng 1,5 tỷ m³ nước mỗi năm, tương đương 2.000 tỷ VND về chi phí công nghệ và nguồn nhân sự để bảo trì. Các khu vực ngoại ô và các khu vực có hạ tầng cũ có tỷ lệ rò rỉ lên đến 45%, gây thiệt hại lớn cho doanh nghiệp water utilities và gây lo lắng về nguồn cung cấp nước sạch.

Định lượng thiệt hại

  • Thiệt hại tài chính: Giá trị mất nước trung bình 30% của tổng tiêu thụ nước, tương đương 2.000 tỷ VND/năm cho các tập đoàn cung cấp nước lớn nguôi.
  • Thời gian phát hiện: Hiện tại, việc phát hiện rò rỉ thường mất 1–2 tuần sau khi rò rỉ xuất hiện, dẫn đến lãng phí hàng tỷ đồng nguôi.
  • Khả năng khắc phục: Các hệ thống quản lý hiện tại chỉ hỗ trợ 10–15% các điểm rò rỉ, còn lại không được phát hiện.

Phạm vi

  • Trong phạm vi: Các mạng ống cung cấp nước ở các thành phố lớn và các khu vực đô thị có dân số trên 500.000 người; các hệ thống đo lường áp suất và dòng lượng được triển khai tại 3 khu thử.
  • Ngoài phạm vi: Các mạng ống nông thôn, hệ thống cấp nước petitesizes, và các chương trình cấp nước hộ gia đình.

Mô hình vấn đề

Mô hình vấn đề được biểu diễn bằng công thức:

Loss=βi=1nΔPiQiPi\text{Loss} = \beta \cdot \sum_{i=1}^{n} \frac{\Delta P_i \cdot Q_i}{P_i}

Trong đó:

  • β\beta — hệ số rò rỉ (độ rao suất), ước tính từ 0,02 đến 0,15
  • ΔPi\Delta P_i — sự giảm áp suất tại đoạn ống ii
  • QiQ_i — lưu lượng chảy qua đoạn ống ii
  • PiP_i — áp suất ban đầu của đoạn ống ii

Ràng buộc:

i=1nΔPiPtotal\sum_{i=1}^{n} \Delta P_i \leq P_{\text{total}} 0β0.20 \leq \beta \leq 0.2

Mục tiêu: Tối thiểu hoá Loss\text{Loss} bằng cách tối ưu hoá vị trí và thời gian phơi bày cảm biến.


Giải pháp đề xuất

LeakGuard là nền tảng B2B2C cho phép:

  • Cơ quan quản lý nước đăng ký các đoạn ống, thiết lập ngưỡng cảnh báo và truy cập dashboard thời gian thực.
  • Hệ thống cảm biến cài đặt tại các điểm chiến lược (đầu thành, núp ống) để thu thập dữ liệu áp suất và dòng lượng mỗi 5 phút.
  • Phân tích AI xử lý dãy thời gian, phát hiện bất thường và tính toán tỉ lệ rò rỉ cho từng đoạn.
  • Công cụvisual cho phép quản lý xem biểu đồ lưu lượng, nhận cảnh báo qua push và lên lịch bảo trì.

Các quyết định thiết kế chính

  • Quyết định 1: Dùng cảm biến cáp trực tiếp (độ chính xác ±0.5%) thay vì cảm biến không dây (độ chính xác ±2%) để giảm nhiễu và cải thiện độ phát hiện.
  • Quyết định 2: Xây dựng dashboard đa nền tảng (web cho cơ quan, app cho nhân viên) để tăng adoption rate lên trên 70% trong giai đoạn MVP.
  • Quyết định 3: Tích hợp FCM (Firebase Cloud Messaging) để gửi cảnh báo ngay lập tức khi rò rỉ được phát hiện, thay vì chỉ gửi email hàng ngày.

Tiêu chí thành công

Tiêu chíMục tiêuPhương pháp đo lường
Tỷ lệ phát hiện rò rỉ> 90% các rò rỉ có khối lượng > 100 m³/ngàySo sánh kết quả với audit guide
Thời gian phản hồi< 4 giờ từ khi phát hiện đến khi thông báo cho nhân viênLog timestamp issue → alert
Giảm thiệt hạiGiảm 20% chi phí water loss trong 12 thángSo sánh trước/sau deploy
Adoption rate> 70% các thành phố lớn tham gia pilotSố lượng account active / tổng số mục tiêu

Luồng hệ thống

Luồng: Cơ quan cấu hình ngưỡng → cảm biến thu thập dữ liệu → AI phân tích → cảnh báo → đội bảo trì sửa chữa.


Thuật toán cốt lõi

Mô tả thuật toán

Progress Matching Algorithm: So sánh lưu lượng thực tế với dự đoán dựa trên mô hình physics, xác định các đoạn có độ lệch lớn.

Bước 1: Thu thập raw data từ cảm biến (áp suất PtP_t, lưu lượng QtQ_t) mỗi 5 phút. Bước 2: Tính toán tốc độ thay đổi áp suất ΔPt=PtPt1\Delta P_t = P_t - P_{t-1}. Bước 3: Compute anomaly score St=αΔPtQtPtS_t = \alpha \cdot \frac{|\Delta P_t| \cdot Q_t}{P_t}, với α\alpha được calibrate từ dữ liệu lịch sử. Bước 4: Nếu StS_t > threshold (được thiết lập bằng quantile 95% của dữ liệu lịch sử), trigger alert và ghi lại vị trí đoạn ống.

Công thức toán học

Anomaly Scoret=αΔPtQtPt\text{Anomaly Score}_t = \alpha \cdot \frac{|\Delta P_t| \cdot Q_t}{P_t}

Các tham số:

  • α\alpha — hệ số level tunable, được tối ưu bằng cross-validation
  • ΔPt|\Delta P_t| — magnitude of pressure drop
  • QtQ_t — flow rate at time tt
  • PtP_t — current pressure

Độ phức tạp

Chỉ sốGiá trị
Độ phức tạp thời gianO(nlogn)O(n \log n) (sort by region)
Độ phức tạp không gianO(m×n)O(m \times n) với mm = số đoạn, nn = số điểm dữ liệu

Kiến trúc hệ thống

+------------------------------------------+
| Frontend (React) |
| +------------------------------------+ |
| | Web Dashboard (Utility) | |
| | - Real-time charts | |
| | - Alert management | |
| | - Report export | |
| +------------------------------------+ |
| +------------------------------------+ |
| | Mobile App (Field Teams) | |
| | - Receive push alerts | |
| | - Log repair actions | |
| +------------------------------------+ |
+------------------------------------------+
|
v
+------------------------------------------+
| API Gateway (Node.js) |
| - JWT authentication |
| - Rate limiting |
| - Request routing |
+------------------------------------------+
|
v
+------------------------------------------+
| Business Logic Layer (Python) |
| +----------------+ +----------------+ |
| | Detection Svc | | Alert Service | |
| | - Compute risk | | - Send push | |
| | - Score models | | notifications| |
| +----------------+ +----------------+ |
+------------------------------------------+
|
v
+------------------------------------------+
| Data Layer (PostgreSQL) |
| - pipe_segments table |
| - sensor_readings table |
| - alerts queue |
+------------------------------------------+
|
v
+------------------------------------------+
| External Services |
| - FCM (Firebase Cloud Messaging) |
| - Cloud Storage (sensor logs) |
| - SMTP (email reports) |
+------------------------------------------+

Mô tả thành phần:

  • Frontend: React-based web dashboard for utilities; React Native mobile app for field crews.
  • API Gateway: Handles authentication, rate limiting, and routes requests.
  • Business Logic: Detection service calculates risk scores; Alert service sends notifications via FCM and email.
  • Data Layer: Stores pipe segment metadata, sensor readings, and alert queues.
  • External Services: FCM for push notifications, Cloud Storage for logs, SMTP for email.

Trường hợp sử dụng

Trường hợp sử dụng 1: Giám sát và bảo trì đoạn ống có rò rỉ

Các tác viên: Đội bảo trì, Hệ thống cảm biến

Tiên điều kiện: Có cảnh báo rò rỉ được kích hoạt

Kích hoạt: Nhận thông báo từ dashboard

Các bước:

  1. Xem thông tin cảnh báo trên dashboard (vị trí, khối lượng mất nước)
  2. Đi đến hiện trường với thiết bị đo lường
  3. Kiểm tra và sửa chữa đoạn ống bị hỏng
  4. Cập nhật kết quả vào hệ thống

Sau điều kiện: Đoạn ống được sửa chữa, trạng thái trở lại bình thường

Kết quả mong đợi: Giảm thiệt hại nước within 24 giờ, không lặp lại

Trường hợp sử dụng 2: Phân tích xu hướng rò rỉ theo khu vực

Các tác viên: Trưởng phòng, Phân tích dữ liệu

Tiên điều kiện: Hoạt động cảm biến trên ít nhất 30 ngày

Kích hoạt: Mở báo cáo xu hướng trong dashboard

Các bước:

  1. Lấy dữ liệu lưu lượng và áp suất từ 30 ngày qua
  2. Phân tích xu hướng giảm áp suất và tăng lưu lượng
  3. Xác định các đoạn ống có nguy cơ rò rỉ potencial
  4. Đề xuất kế hoạch kiểm tra định kỳ

Sau điều kiện: Kế hoạch bảo trì được lên lịch cho quý tới

Kết quả mong đợi: Phát hiện sớm 15% rò rỉ tiềm ẩn trước khi xảy ra


Mô hình kinh doanh

Mô hình doanh thu

R=(pUtility×qUtility)+(pPartner×qPartner)CoperR = (p_{\text{Utility}} \times q_{\text{Utility}}) + (p_{\text{Partner}} \times q_{\text{Partner}}) - C_{\text{oper}}

Các thành phần:

  • pUtilityp_{\text{Utility}} = 50 triệu VND/năm cho mỗi khách hàng corporate
  • qUtilityq_{\text{Utility}} = 1 (mỗi cơ quan)
  • pPartnerp_{\text{Partner}} = 20 triệu VND/năm cho mỗi đối tác thiết bị IoT
  • qPartnerq_{\text{Partner}} = số lượng đối tác (dự kiến 50 vào năm 2)
  • CoperC_{\text{oper}} = chi phí vận hành ước tính 1,5 tỷ VND/năm

Cấu trúc chi phí

Loại chi phíMô tảSố tiền
Cloud infrastructure (AWS/GCP)Compute, storage, CDN300 triệu VND/năm
Development team (5 engineers)Lương + benefits1,2 tỷ VND/năm
Support team (2 persons)Helpdesk, training300 triệu VND/năm
Sales & MarketingDemo events, docs200 triệu VND/năm

Phân tích điểm hòa vốn

Break-even Volume=CfixedpUtilitycunit\text{Break-even Volume} = \frac{C_{\text{fixed}}}{p_{\text{Utility}} - c_{\text{unit}}}
  • CfixedC_{\text{fixed}} = 2 tỷ VND/năm (fixed costs)
  • cunitc_{\text{unit}} = 50 triệu VND/đơn vị (variable support cost)
  • pUtilityp_{\text{Utility}} = 50 triệu VND/năm

Điểm hòa vốn: Khi có 250 Utility khách hàng, doanh thu = 2,5 tỷ → hòa vốn. Dự kiến đạt 300 khách hàng trong năm 2.


Kế hoạch MVP

Giai đoạn 1: Hạ tầng cốt lõi (Tuần 1–4)

  • Thiết kế database schema (pipe segments, sensor readings, alerts)
  • Setup auth service (JWT, roles: Utility/Field)
  • Build basic mobile app: login, list pipe segments, receive alerts
  • Build basic web dashboard: list segments, view real-time charts
  • Deploy staging environment on AWS

Tiêu chí kết thúc: User có thể đăng nhập, xem danh sách đoạn ống và nhận thông báo cảnh báo.

Giai đoạn 2: Tính năng cảnh báo và notification (Tuần 5–8)

  • Alert service: cron job nightly check KPI vs target
  • Push notification integration (FCM)
  • Email notification backend
  • Alert dashboard với filtering (urgent/warning)
  • Unit tests coverage >80%

Tiêu chí kết thúc: KPI < 80% tự động tạo alert và gửi push đến Utility/Sở liên quan.

Giai đoạn 3: Pilot với 3 Utility & 10 Field Teams (Tuần 9–12)

  • Onboard 3 Utility (Hanoi, HCMC, Da Nang)
  • Onboard 10 Field Teams (3 per Utility)
  • Conduct training sessions
  • Collect feedback survey and iterate
  • Deploy production

Tiêu chí kết thúc: 90% pilot users active, 0 critical bugs, official report from Utility.


Các yêu cầu

Yêu cầu 1: LeakGuard phải cho phép Utility theo dõi tiến độ của 10.000 đoạn ống trong hệ thống cấp nước, với độ trễ cập nhật dưới 4 giờ, cho phép phát hiện sớm rò rỉ và giảm thiệt hại water loss 20% trong 12 tháng.

Yêu cầu 2: Hệ thống phải tự động phát hiện ít nhất 90% các đoạn ống có lưu lượng giảm >15% so với mức trung bình lịch sử trong vòng 48 giờ kể từ khi phát hiện, và gửi cảnh báo đến Utility và đội bảo trì có thẩm quyền.

Yêu cầu 3: Trong vòng 12 tuần sau khi release, LeakGuard phải đạt ít nhất 70% adoption rate tại các Utility tham gia pilot, với 90% người dùng active và không có bug nghiêm trọng, nhờ vào mobile app dễ sử dụng và push notification cảnh báo tự động.


Claims

Claim 1: LeakGuard giảm thời gian phát hiện rò rỉ từ 1–2 tuần xuống còn dưới 4 giờ, cải thiện thời gian phản hồi lên 95% so với phương pháp thủ công hiện nay.

Claim 2: LeakGuard giảm thiệt hại water loss lên tới 20% trong vòng 12 tháng triển khai, tương đương việc tiết kiệm tới 400 triệu m³ nước và 400 tỷ VND cho mỗi triệu dân được phục vụ.

Claim 3: LeakGuard đạt tỷ lệ phát hiện rò rỉ chính xác trên 90% cho các đoạn ống có mất nước >100 m³/ngày, giảm mức độ falso positivo dưới 5%.

Claim 4: LeakGuard giúp tăng adoption rate lên trên 70% trong giai đoạn MVP nhờ vào thiết bị cảm biến cáp trực tiếp và dashboard đa nền tảng.

Quyền sở hữu & Bản quyền

© 2026 Alpha Chain Co., Ltd. Tất cả quyền được bảo lưu.

Tài liệu này là tài sản độc quyền của Alpha Chain Co., Ltd. Việc sao chép, phân phối lại, hoặc tạo sản phẩm phái sinh đều yêu cầu sự đồng ý bằng văn bản từ Alpha Chain Co., Ltd.


Lịch sử thay đổi

Phiên bảnNgàyTác giảThay đổi
1.02026-04-30Alpha Chain Co., Ltd.Tạo ban đầu từ ý tưởng phát hiện rò rỉ nước