Smart Water Metering · TVT Group, 2021–2024

Hệ thống đo nước quy mô thành phố tách biệt luồng ghi (ingest) và luồng đọc (read)

Đồng hồ nước hộ gia đình trên khắp thành phố gửi dữ liệu định kỳ về trung tâm giám sát. Nguy cơ đóng băng đường ống và hiện tượng nước chảy ngược được phát hiện dựa trên chuỗi biến thiên theo thời gian (time-window pattern), thay vì chỉ nhìn vào một bản tin đơn lẻ.

MQTT · RabbitMQ · Node.js · PostgreSQL

Kết quả: Giám sát vận hành mạng lưới đồng hồ nước hộ gia đình quy mô thành phố lớn; phát cảnh báo theo chuỗi thời gian (time window) thay vì từng mẫu rời rạc.

Bài toán thực tế

Đội vận hành cần theo dõi tình trạng mạng lưới cấp nước từ các đồng hồ hộ gia đình — bao gồm nguy cơ đóng băng ống và hiện tượng chảy ngược — mà các thao tác mở dashboard tra cứu không được làm nghẽn luồng tiếp nhận dữ liệu vào giờ cao điểm.

Số lượng thiết bị quy mô toàn thành phố; lưu lượng bản tin gửi về dồn cục bộ (burst) theo từng khung giờ.
Các quy tắc cảnh báo như nguy cơ đóng băng cần đánh giá trên một cửa sổ thời gian (time window), không thể kết luận từ một gói tin đơn lẻ.
Phép tính lưu lượng (flow rate) từng hộ phải xử lý chính xác ngay cả khi đồng hồ bị reset hoặc gửi bản tin lệch mốc thời gian (timestamp).
Hệ thống hỗ trợ nhiều đơn vị vận hành (multi-tenant); mỗi tổ chức chỉ được phép truy cập phạm vi mạng lưới của mình.

Kiến trúc hệ thống

flowchart LR
  subgraph edge ["Meters"]
    edge_0(["Household water meters"])
  end
  subgraph ingest ["Ingest"]
    ingest_0["Thin validation and timestamping"]
    ingest_1[["Ingest queue"]]
    ingest_2["Batch insert writers"]
  end
  subgraph read ["Read path"]
    read_0[("Operational store")]
    read_1["Pre-aggregated rollups"]
    read_2["Rule engine for freezing and reverse flow"]
    read_3["Operator dashboards"]
  end
  edge_0 --> ingest_0
  ingest_0 --> ingest_1
  ingest_1 --> ingest_2
  ingest_2 --> read_0
  read_0 --> read_1
  read_1 --> read_2
  read_2 --> read_3

Các quyết định kiến trúc then chốt

Đánh giá nguy cơ đóng băng và chảy ngược trên cửa sổ thời gian (time window)

Kiểm tra điều kiện đóng băng và chảy ngược dựa trên chuỗi mẫu đo đã sắp xếp theo trình tự thời gian trong một khoảng cửa sổ xác định, không kết luận từ một bản tin riêng lẻ.

Một mẫu đo nhiễu đơn lẻ sẽ gây báo động giả liên tục cho vận hành viên; thứ nghiệp vụ cần phát hiện là trạng thái bất thường kéo dài.

Phương án đã loại bỏ: So khớp ngưỡng (threshold) trực tiếp trên từng bản tin thô ngay khi vừa nhận — loại bỏ sau khi gây ra quá nhiều cảnh báo giả ở giai đoạn thử nghiệm (pilot).

Đánh đổi: Cơ chế cửa sổ thời gian phải xử lý được các bản tin đến trễ (late-arriving samples) mà không đóng cảnh báo quá sớm.

Tính lưu lượng (flow rate) từ độ chênh thể tích chia cho độ chênh thời gian

Tính lưu lượng dựa trên chênh lệch chỉ số thể tích tích lũy (delta volume / delta time), có xử lý các trường hợp đồng hồ reset về 0, bản tin trùng timestamp hoặc đồng hồ bị trôi ngược giờ.

Biểu đồ giám sát sẽ bị sai lệch nghiêm trọng nếu một lần reset đồng hồ bị tính nhầm thành mức tiêu thụ âm đột biến.

Phương án đã loại bỏ: Lưu trực tiếp giá trị lưu lượng tức thời do thiết bị tự báo lên mà không đối soát — loại bỏ vì sai lệch ngay khi thiết bị gửi lặp bản tin (duplicate retry).

Đánh đổi: Tăng độ phức tạp ở bước xử lý đầu vào, nhưng đảm bảo số liệu trên biểu đồ vận hành luôn đáng tin cậy.

Ghi theo lô (batch insert) và cho dashboard đọc từ bảng tổng hợp (rollup)

Các worker gom bản tin để ghi theo lô (batch insert); màn hình dashboard chỉ truy vấn trên các bảng đã tổng hợp sẵn (pre-aggregated rollups) thay vì đọc trực tiếp bảng ingest.

Lưu lượng dữ liệu đổ về vào giờ cao điểm không được phép tranh chấp tài nguyên với các câu lệnh GROUP BY nặng từ người dùng.

Phương án đã loại bỏ: Dùng chung một bảng PostgreSQL cho cả việc ghi dữ liệu trực tiếp lẫn truy vấn phân tích — loại bỏ ngay sau khi kiểm thử tải (load test).

Đánh đổi: Cần duy trì tiến trình cập nhật bảng rollup liên tục; số liệu trên biểu đồ có độ trễ vài giây so với thời gian thực.

Phần tôi chịu trách nhiệm, trực tiếp viết và phân công

Chịu trách nhiệm (Own)

  • Kiến trúc backend thu thập dữ liệu cảm biến (telemetry) và đưa về hệ thống giám sát tập trung
  • Thiết kế cơ chế tách bạch tải ghi dữ liệu (ingest workload) khỏi tải truy vấn của dashboard

Trực tiếp viết (Write)

  • Thuật toán phân tích và phát cảnh báo nguy cơ đóng băng (freezing-risk) cùng hiện tượng nước chảy ngược (reverse-flow)
  • Bộ tính toán lưu lượng tiêu thụ (flow rate) của từng hộ gia đình phục vụ giám sát toàn mạng lưới

Phân công (Delegate)

  • Nghiệp vụ tính cước và biểu giá (billing & tariff) nằm ở hệ thống khác, ngoài phạm vi backend giám sát này

Quy mô vận hành

  • Triển khai thực tế ở quy mô thành phố lớn tại nước ngoài
  • Phục vụ giám sát vận hành chủ động, giúp kỹ thuật viên can thiệp sớm trước khi vỡ ống hoặc gián đoạn cấp nước

Ranh giới phạm vi

  • Hệ thống thu thập dữ liệu từ đồng hồ nước hộ gia đình trên phạm vi một thành phố lớn; số lượng thiết bị cụ thể và tổng dung lượng lưu trữ hằng ngày thuộc phạm vi quản lý của đơn vị vận hành.
  • Phần mềm nhúng (firmware) trên đồng hồ do nhà sản xuất phần cứng phụ trách; phạm vi của backend bắt đầu từ khi gói tin telemetry được gửi lên.

Các chỉ số giám sát khi vận hành

Tốc độ tiếp nhận bản tin (ingest rate) so với độ trễ xử lý của worker (consumer lag)Số lượng cảnh báo nguy cơ đóng băng và chảy ngược phát sinh theo giờTỷ lệ bản tin đến trễ hoặc sai thứ tự thời gian (out-of-order) trong mỗi giờ

Nguyên tắc bất di bất dịch trong thiết kế

  • Các truy vấn từ màn hình dashboard không bao giờ được dùng chung connection pool với luồng ghi dữ liệu (ingest).
  • Mọi API đọc dữ liệu đều phải áp dụng bộ lọc cô lập theo tenant.
  • Các bản ghi bất thường của đồng hồ được cập nhật (upsert) theo cặp khóa thiết bị và mốc thời gian, tuyệt đối không tính trùng hai lần.

Phạm vi ứng dụng rộng hơn

  • Hệ thống thu thập dữ liệu tiện ích đô thị (utility telemetry) có đặc thù lưu lượng dồn cục bộ theo khung giờ.
  • Mạng lưới cấp nước sử dụng hiện tượng chảy ngược và nguy cơ đóng băng làm tín hiệu cảnh báo bảo trì sớm.
  • Các nền tảng dữ liệu lớn cần chuyển dịch từ mô hình truy vấn trực tiếp sang tách biệt luồng ghi và mô hình đọc (CQRS / read model).