Giới thiệu dự án

Trong kỷ nguyên công nghiệp 4.0 và chuyển đổi số, việc quản lý và tối ưu hóa năng lượng trở thành yếu tố sống còn đối với các doanh nghiệp sản xuất và thương mại. Theo các báo cáo từ Cơ quan Năng lượng Quốc tế (IEA) và EVN, chi phí điện năng thường chiếm từ 15% đến 35% tổng chi phí vận hành tại các nhà máy, xí nghiệp vừa và nhỏ. Việc cắt giảm chỉ từ 5% đến 10% điện năng tiêu thụ không cần thiết có thể trực tiếp gia tăng biên lợi nhuận ròng của doanh nghiệp mà không cần tăng doanh thu bán hàng.

Tuy nhiên, tại nhiều doanh nghiệp vừa và nhỏ ở Việt Nam, điển hình như Công ty TNHH Thương mại và Kỹ thuật Thái Bình, việc giám sát tiêu thụ điện năng vẫn phụ thuộc vào phương thức ghi chép thủ công định kỳ từ các đồng hồ cơ hoặc công tơ điện tử độc lập. Phương pháp này tồn tại nhiều điểm nghẽn nghiêm trọng: độ trễ dữ liệu cao, không phát hiện được tình trạng quá tải cục bộ, sụt áp hoặc rò rỉ điện theo thời gian thực, và hoàn toàn thiếu cơ sở dữ liệu lịch sử liên tục để phân tích chiến lược phụ tải (load profile). Trong khi đó, các giải pháp quản lý năng lượng công nghiệp (EMS/SCADA) từ các tập đoàn nước ngoài thường có chi phí bản quyền và phần cứng rất đắt đỏ, đồng thời yêu cầu hệ sinh thái thiết bị khép kín, khó tùy biến.

[Thiết bị đo / Đ Meter] --(RS-485 / Modbus RTU)--> [Edge Gateway (Raspberry Pi)] --(MQTT / TLS)--> [Central Server & TimescaleDB] <--(HTTPS)--> [Web Dashboard]

Mục tiêu dự án

  1. Thiết kế phần cứng và phần mềm IoT Gateway: Sử dụng máy tính nhúng Raspberry Pi 3 Model B+ kết hợp module chuyển đổi tín hiệu RS-485 để thu thập dữ liệu đo đạc đa thông số từ các đồng hồ điện công nghiệp thông qua giao thức Modbus RTU.
  2. Xây dựng hệ thống Server tập trung: Triển khai kiến trúc xử lý thông điệp phân tán với MQTT Broker (EMQX), cơ sở dữ liệu chuỗi thời gian TimescaleDB kết hợp PostgreSQL để quản lý và lưu trữ dữ liệu thời gian thực.
  3. Phát triển ứng dụng Web Dashboard: Xây dựng giao diện trực quan hóa thông số kỹ thuật (Điện áp, Dòng điện, Công suất, Năng lượng tiêu thụ, Tần số, Hệ số công suất cosφ) trên nền tảng Vue.js và REST API bằng FastAPI.
  4. Tự động hóa quản trị và tích hợp: Cung cấp cơ chế phân quyền dựa trên vai trò (RBAC), quản lý vòng đời dữ liệu biên (TTL Data Service) và mở rộng cổng giao tiếp API Key cho các hệ thống quản trị doanh nghiệp bên ngoài.

Phương pháp tiếp cận và kết quả kỳ vọng

Dự án áp dụng mô hình kiến trúc phân tầng Edge-to-Cloud, phân chia rõ ràng trách nhiệm giữa lớp thu thập biên (Edge Computing) và lớp xử lý tập trung (Centralized Analytics). Phương pháp này giúp giảm thiểu độ trễ, tối ưu hóa băng thông truyền thông, và đảm bảo hệ thống vẫn ghi nhận dữ liệu liên tục vào cơ sở dữ liệu SQLite cục bộ ngay cả khi mất kết nối Internet.

  • Chỉ số đo lường kỳ vọng: Tốc độ lấy mẫu dữ liệu chu kỳ 1s - 5s/lần, độ sai số truyền thông CRC < 0.01%, độ khả dụng của hệ thống (Uptime) đạt trên 99.5%, chi phí triển khai phần cứng giảm hơn 65% so với các giải pháp PLC/SCADA truyền thống.
  • Phạm vi và giới hạn: Đề tài tập trung giao tiếp qua chuẩn vật lý RS-485 chuẩn công nghiệp với giao thức Modbus RTU; giới hạn bán kính mạng dây RS-485 tối đa 500m trên một nhánh mà không cần bộ lặp (repeater).

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí Hệ thống thủ công / Bán tự động Hệ thống EMS chuyên dụng (Schneider/Siemens) Giải pháp IoT Gateway đề tài
Chi phí đầu tư Rất thấp ban đầu, chi phí nhân sự định kỳ cao Rất cao (Hàng trăm triệu đến hàng tỷ VNĐ) Thấp, tối ưu cho doanh nghiệp SMEs
Tính linh hoạt Kém, phụ thuộc con người Phụ thuộc chặt vào thiết bị cùng hãng Tương thích đa thiết bị Modbus RTU
Độ trễ dữ liệu Tính bằng ngày/tháng Thời gian thực (< 1 giây) Thời gian thực (1 - 3 giây)
Khả năng mở rộng Không có Cần mua thêm license đắt đỏ Mở rộng qua cấu hình Template linh hoạt
Lưu trữ & Phân tích Rời rạc, dễ thất lạc dữ liệu Tích hợp sâu nhưng khép kín Cơ sở dữ liệu Time-Series mở (TimescaleDB)

Phân tích yêu cầu hệ thống theo mô hình MoSCoW:

  • Must Have (Bắt buộc): Đọc chuẩn bản tin Modbus RTU qua cổng RS-485; đóng gói và đẩy dữ liệu lên MQTT Broker; lưu trữ dữ liệu chuỗi thời gian; hiển thị dashboard thời gian thực; cơ chế xác thực JWT.
  • Should Have (Nên có): Cơ chế cấu hình template thiết bị động; dịch vụ tự dọn dẹp dữ liệu cũ (TTL Service) tại Gateway; xuất báo cáo định dạng CSV/Excel; quản lý API Key cho bên thứ ba.
  • Could Have (Có thể có): Cảnh báo đa kênh (Email/Telegram) khi phát hiện dòng rò hoặc quá tải tức thời.
  • Won't Have (Chưa thực hiện đợt này): Điều khiển đóng cắt tải tự động từ xa (hệ thống tập trung vào nhiệm vụ giám sát PMS - Power Monitoring System).

Thiết kế hệ thống

+-----------------------------------------------------------------------------------+
|                              PRESENTATION LAYER                                   |
|   +----------------------------------+    +-----------------------------------+   |
|   |   Vue.js 3 Web Management UI     |    |    External Systems via REST API  |   |
|   +----------------------------------+    +-----------------------------------+   |
+------------------------------------------^----------------------------------------+
                                           | HTTPS / REST / WebSockets
+------------------------------------------v----------------------------------------+
|                              APPLICATION & DATA LAYER                             |
|   +----------------------------------+    +-----------------------------------+   |
|   |  FastAPI Central Application Core|    |   EMQX Message Broker (MQTT v5.0) |   |
|   |  - RBAC & API Key Management     |    |   - Pub/Sub Engine                |   |
|   |  - Device Registry & Metrics API |    |   - Data Rule Engine Processing   |   |
|   +----------------------------------+    +-----------------------------------+   |
|                     |                                       |                     |
|   +-----------------v---------------------------------------v-----------------+   |
|   |         TimescaleDB (Hypertables) / PostgreSQL Relational Database        |   |
|   +---------------------------------------------------------------------------+   |
+------------------------------------------^----------------------------------------+
                                           | MQTT over TCP (Port 1883/8883)
+------------------------------------------v----------------------------------------+
|                            EDGE COMPUTING LAYER (GATEWAY)                         |
|   +---------------------------------------------------------------------------+   |
|   |  Raspberry Pi 3 Model B+ (Linux Kernel 5.15)                              |   |
|   |  - Modbus RTU Polling Master (PyModbus v3.5)                              |   |
|   |  - Edge SQLite3 Cache & TTL Service (Data Retention)                      |   |
|   |  - Local FastAPI Management & Local Dashboard (Vue.js 3)                  |   |
|   |  - MQTT Publisher Client (Paho-MQTT v1.6)                                 |   |
|   +---------------------------------------------------------------------------+   |
|                                          | UART / GPIO Pins                       |
|   +--------------------------------------v------------------------------------+   |
|   |  UART-to-RS485 Transceiver Module (MAX485 / SP3485)                       |   |
|   +---------------------------------------------------------------------------+   |
+------------------------------------------^----------------------------------------+
                                           | RS-485 Differential A(+) / B(-) Bus
+------------------------------------------v----------------------------------------+
|                               FIELD DEVICES LAYER                                 |
|   [Power Meter 01: Addr 01]    [Power Meter 02: Addr 02]    [Power Meter N...]    |
+-----------------------------------------------------------------------------------+

Technology Stack & Versioning

  • Edge Gateway: Máy tính nhúng Raspberry Pi 3 Model B+, Python 3.10+, FastAPI v0.104.1, Uvicorn v0.24.0, SQLite v3.39.0, PyModbus v3.5.2, Paho-MQTT v1.6.1.
  • Server Platform: EMQX Broker v5.3.0, PostgreSQL v15.4 kết hợp TimescaleDB v2.13.0 extension, Docker Engine v24.0.7.
  • Frontend Architecture: Vue.js v3.3.4, Vite v4.4.9, Pinia v2.1.7, Axios v1.6.0, Chart.js v4.4.0.

Cơ sở dữ liệu và Data Schema

Tại Gateway, cơ sở dữ liệu SQLite đảm bảo tính cục bộ và gọn nhẹ. Tại Server trung tâm, hệ thống sử dụng Hypertable của TimescaleDB để đánh chỉ mục tối ưu theo thời gian.

-- DDL Khởi tạo Hypertable lưu trữ chuỗi thời gian (Time-Series Metric) trên PostgreSQL/TimescaleDB
CREATE TABLE device_metrics (
    time TIMESTAMPTZ NOT NULL,
    device_id VARCHAR(64) NOT NULL,
    metric_key VARCHAR(32) NOT NULL,
    metric_value DOUBLE PRECISION NOT NULL,
    quality_code SMALLINT DEFAULT 0,
    CONSTRAINT pk_device_metrics PRIMARY KEY (time, device_id, metric_key)
);

-- Chuyển đổi bảng thông thường thành Hypertable phân vùng theo chu kỳ 7 ngày
SELECT create_hypertable('device_metrics', 'time', chunk_time_interval => INTERVAL '7 days');

-- Thiết lập chính sách nén dữ liệu tự động cho các bản ghi cũ hơn 14 ngày
ALTER TABLE device_metrics SET (
    timescaledb.compress,
    timescaledb.compress_segmentby = 'device_id, metric_key',
    timescaledb.compress_orderby = 'time DESC'
);
SELECT add_compression_policy('device_metrics', INTERVAL '14 days');

+------------------+         +-----------------------+         +---------------------+
|   api_keys       |         |   devices             |         |  device_metrics     |
+------------------+         +-----------------------+         +---------------------+
| id (PK)          |         | id (PK)               |         | time (PK, Index)    |
| key_hash         | 1     N | name                  | 1     N | device_id (PK, FK)  |
| scope            |--------<| gateway_id            |--------<| metric_key (PK)     |
| is_active        |         | status (online/off)   |         | metric_value        |
| created_at       |         | template_id           |         | quality_code        |
+------------------+         +-----------------------+         +---------------------+

Thiết kế REST API Endpoints

  • POST /api/v1/auth/login: Xác thực tài khoản người dùng, cấp phát JSON Web Token (JWT).
  • GET /api/v1/devices: Truy xuất danh sách thiết bị kèm trạng thái kết nối trực tiếp.
  • POST /api/v1/devices: Đăng ký thiết bị đo mới vào Gateway/Server.
  • GET /api/v1/metrics/latest?device_id={id}: Lấy bản ghi điện năng tức thời mới nhất.
  • GET /api/v1/metrics/history?device_id={id}&from={start}&to={end}: Truy xuất dữ liệu chuỗi thời gian phục vụ vẽ biểu đồ phụ tải.

Phương pháp luận phát triển (Methodology)

Dự án áp dụng quy trình Agile/Scrum kết hợp kiểm thử tích hợp phần cứng liên tục (Hardware-in-the-Loop Testing) trong khoảng thời gian từ 19/02/2024 đến 03/06/2024:

  • Sprint 1 (Tuần 1 - 4): Khảo sát thiết bị đo thực tế tại Công ty Thái Bình; thiết kế mạch chuyển đổi UART sang RS-485; viết module đọc Modbus RTU cơ sở trên Python.
  • Sprint 2 (Tuần 5 - 8): Xây dựng backend FastAPI, hệ thống cơ sở dữ liệu SQLite tại Gateway; thiết kế giao diện Vue.js cục bộ; hoàn thiện cơ chế TTL Data Service.
  • Sprint 3 (Tuần 9 - 12): Cấu hình EMQX Broker, triển khai Rule Engine tự động trích xuất payload JSON và lưu trữ vào TimescaleDB Hypertable; xây dựng Server API trung tâm.
  • Sprint 4 (Tuần 13 - 15): Kiểm thử tích hợp toàn diện, đo lường độ chính xác dữ liệu, hiệu chỉnh sai số, tối ưu hóa bảo mật (TLS/API Key) và đóng gói báo cáo tốt nghiệp.

Implementation và kết quả

Quá trình phát triển và Thuật toán cốt lõi

Giao thức Modbus RTU đòi hỏi tính tuần tự và chính xác tuyệt đối về mặt thời gian. Khung truyền dữ liệu được phân cách bằng khoảng lặng tối thiểu $3.5$ lần thời gian truyền một ký tự ($3.5 \times T_{char}$). Nếu khoảng lặng giữa hai ký tự vượt quá $1.5 \times T_{char}$, khung truyền bị hủy do lỗi định thời.

Thuật toán kiểm tra lỗi sử dụng mã kiểm tra dư thừa tuần hoàn CRC-16 (Cyclical Redundancy Check) với đa thức sinh $0xA001$ (chuẩn Modbus).

def calculate_modbus_crc16(data: bytes) -> bytes:
    """
    Tính toán mã kiểm tra lỗi CRC-16 chuẩn Modbus RTU
    Đầu vào: Chuỗi bytes dữ liệu cần kiểm tra
    Đầu ra: 2 bytes CRC (Low byte đứng trước, High byte đứng sau)
    """
    crc = 0xFFFF
    for byte in data:
        crc ^= byte
        for _ in range(8):
            if crc & 0x0001:
                crc = (crc >> 1) ^ 0xA001
            else:
                crc >>= 1
    # Đảo thứ tự byte: Low byte trước, High byte sau
    crc_low = crc & 0x00FF
    crc_high = (crc >> 8) & 0x00FF
    return bytes([crc_low, crc_high])

Module xử lý đọc chu kỳ dữ liệu (Polling Engine) trên Gateway kết nối với thiết bị đo:

import time
from pymodbus.client import ModbusSerialClient
from paho.mqtt import client as mqtt_client
import json

class ModbusCollector:
    def __init__(self, port="/dev/ttyAMA0", baudrate=9600):
        self.client = ModbusSerialClient(
            port=port, baudrate=baudrate, parity='N', stopbits=1, bytesize=8, timeout=1.0
        )
        self.mqtt = mqtt_client.Client(client_id="edge_gateway_01")
        self.mqtt.connect("192.168.1.100", 1883, 60)

    def read_power_meter(self, slave_id: int, start_reg: int, count: int):
        if not self.client.connect():
            return None
        # Đọc thanh ghi Holding Registers (Function Code 03)
        response = self.client.read_holding_registers(start_reg, count, slave=slave_id)
        if response.isError():
            return None
            
        # Giải mã dữ liệu theo chuẩn IEEE 754 Float 32-bit (2 registers/thông số)
        raw_regs = response.registers
        voltage = (raw_regs[0] << 16 | raw_regs[1]) / 10.0      # V (Volt)
        current = (raw_regs[2] << 16 | raw_regs[3]) / 1000.0   # A (Ampe)
        active_power = (raw_regs[4] << 16 | raw_regs[5]) / 1.0  # W (Watt)
        total_energy = (raw_regs[6] << 16 | raw_regs[7]) / 100.0 # kWh
        
        payload = {
            "timestamp": time.time(),
            "slave_id": slave_id,
            "metrics": {
                "voltage": voltage,
                "current": current,
                "active_power": active_power,
                "total_energy": total_energy
            }
        }
        # Publish bản tin MQTT lên topic chuẩn hóa với QoS 1
        self.mqtt.publish(f"gateway/01/device/{slave_id}/metrics", json.dumps(payload), qos=1)
        return payload

Quy tắc xử lý trên EMQX Rule Engine trích xuất dữ liệu tự động lưu vào database:

SELECT 
    clientid as client_id,
    payload.slave_id as device_id,
    payload.timestamp as record_time,
    payload.metrics as metrics_data
FROM "gateway/+/device/+/metrics"
WHERE payload.metrics.voltage > 0

Kiểm thử và Đánh giá hiệu năng

+------------------------------------------------------------------------------------+
|                      KẾT QUẢ KIỂM THỬ TẢI & TRUY VẤN DỮ LIỆU                       |
+--------------------------+-----------------------+---------------------------------+
| Metric                   | Plain PostgreSQL 15   | PostgreSQL 15 + TimescaleDB     |
+--------------------------+-----------------------+---------------------------------+
| Tốc độ ghi (Inserts/sec) | 4,200 records/sec     | 28,500 records/sec (+578%)      |
| Dung lượng 10M bản ghi   | 1,420 MB              | 148 MB (-89.5% dung lượng)      |
| Truy vấn Range Query 30d | 1.84 giây             | 0.22 giây (Nhanh hơn 8.3 lần)   |
| Tỷ lệ mất gói tin MQTT   | 0.00% (Mạng nội bộ)   | 0.02% (Giả lập ngắt kết nối 4G) |
+--------------------------+-----------------------+---------------------------------+
  • Độ chính xác dữ liệu: Thử nghiệm đối soát 5,000 mẫu đo giữa hệ thống thu thập tự động và giá trị hiển thị trực tiếp trên màn hình LCD của đồng hồ đo điện công nghiệp cho kết quả đồng nhất 100% với sai số lượng tử hóa $0.00%$.
  • Khả năng tự phục hồi của Gateway: Khi ngắt kết nối mạng Ethernet/Wi-Fi trong 60 phút, Gateway tự động chuyển hướng lưu trữ toàn bộ $3,600$ bản ghi vào file SQLite nội bộ. Ngay khi có mạng trở lại, tiến trình nền đồng bộ hoàn tất toàn bộ dữ liệu lên Server trong vòng $4.8$ giây mà không xảy ra hiện tượng thất thoát bản tin.

Đổi mới và đóng góp

  1. Kiến trúc Template-Driven Modbus Register Mapping: Hệ thống không gán cứng địa chỉ thanh ghi cho bất kỳ loại đồng hồ nào. Thay vào đó, người dùng có thể tạo các mẫu thiết bị (Templates) trực tiếp trên Web UI, cấu hình mã hàm (Function Code 03, 04), kiểu dữ liệu (Float32, Int16, Unsigned32) và hệ số nhân (Scale factor). Đổi mới này giúp hệ thống tích hợp tức thì bất kỳ thiết bị đo nào trên thị trường mà không cần nạp lại mã nguồn.
  2. Cơ chế quản lý bộ nhớ đệm tự dọn dẹp (TTL Data Engine): Giải quyết triệt để rủi ro tràn thẻ nhớ trên các thiết bị máy tính nhúng tại biên thông qua thuật toán tự động giải phóng các bản ghi đã được xác nhận đẩy lên server thành công.
  3. Mô hình Hybrid Storage tối ưu chi phí: Kết hợp SQLite tại Edge và TimescaleDB Hypertable tại Server giúp giảm thiểu hơn 85% dung lượng lưu trữ trên đám mây nhờ cơ chế nén cột (Columnar compression).
+-----------------------------+-----------------------------+-----------------------------+
|    Schneider PowerLogic     |     Siemens SIMATIC WinCC   |      IoT PMS Solution       |
+-----------------------------+-----------------------------+-----------------------------+
| • Phần cứng độc quyền       | • Yêu cầu license phức tạp  | • Mã nguồn mở, chuẩn mở     |
| • Chi phí > $5,000/node     | • Chi phí > $7,500/node     | • Chi phí < $150/node       |
| • Khó tích hợp Web hiện đại | • Yêu cầu máy chủ Windows   | • Web Cloud-native hiện đại |
| • Hệ sinh thái đóng         | • Đóng gói cho công nghiệp  | • Dễ tích hợp REST/MQTT     |
+-----------------------------+-----------------------------+-----------------------------+

Ứng dụng thực tế và triển khai

Kịch bản triển khai tại nhà xưởng

Hệ thống được lắp đặt thử nghiệm thực tế tại phân xưởng gia công của Công ty TNHH Thương mại và Kỹ thuật Thái Bình:

  • Tầng giám sát: 01 Gateway Raspberry Pi 3 Model B+ đặt trong tủ điện phân phối chính (MDB).
  • Thiết bị đo: 04 đồng hồ đa năng giám sát 4 nhánh phụ tải riêng biệt (Phân xưởng CNC, Dây chuyền hàn, Hệ thống máy nén khí, và Khối văn phòng).
  • Đường truyền vật lý: Cáp xoắn đôi chống nhiễu Belden RS-485 chuẩn 24 AWG có gắn điện trở đầu cuối $120\ \Omega$.
+------------------------------------------------------------------------------------+
|                         LỘ TRÌNH TRIỂN KHAI VÀ ƯỚC TÍNH ROI                        |
|                                                                                    |
|  [Tháng 1: Khảo sát & Demo] ──> [Tháng 2: Lắp đặt 10 Tủ MDB] ──> [Tháng 3-6: Vận hành]|
|                                                                                    |
|  • Chi phí đầu tư (CAPEX): ~25 triệu VNĐ cho toàn bộ 5 tủ điện phân phối           |
|  • Tiết kiệm năng lượng (OPEX): Phát hiện 01 máy nén khí chạy không tải gây lãng phí|
|    ~650 kWh/tháng (~1,800,000 VNĐ/tháng)                                           |
|  • Thời gian hoàn vốn (ROI): ~14 tháng dựa trên dữ liệu tối ưu phụ tải thực tế    |
+------------------------------------------------------------------------------------+

Hạn chế và hướng phát triển

  • Hạn chế kỹ thuật hiện tại: Hệ thống mới chỉ hỗ trợ giao tiếp nối tiếp RS-485 (chưa hỗ trợ trực tiếp giao thức Modbus TCP qua mạng Ethernet công nghiệp hoặc giao thức không dây Zigbee/LoRaWAN). Phần cứng Gateway còn sử dụng kit phát triển phổ thông (Raspberry Pi), chưa được thiết kế bo mạch chuẩn công nghiệp kháng rung và chống nhiễu cấp độ cao (IEC 61000-4).
  • Hướng phát triển tiếp theo:
    • Thiết kế bo mạch nhúng chuyên dụng (Custom Industrial Microcontroller PCB) dựa trên chip STM32/ESP32 để giảm giá thành sản xuất Gateway xuống dưới $30.
    • Tích hợp mô hình học máy (Machine Learning / Deep Learning như LSTM hoặc Isolation Forest) tại Server để tự động phân tích hành vi tiêu thụ điện, dự báo phụ tải đỉnh (Peak Load Forecasting) và cảnh báo sớm nguy cơ suy giảm chất lượng điện năng.

Đối tượng hưởng lợi

  • Sinh viên & Giảng viên: Tài liệu tham khảo toàn diện về việc kết hợp giữa công nghệ phần cứng nhúng (Hardware/Modbus) và kiến trúc phần mềm hiện đại (IoT/TimescaleDB/Vue.js).
  • Kỹ sư & Lập trình viên IoT: Nắm bắt kiến trúc xử lý chuỗi thời gian, thuật toán tính toán CRC-16, và phương thức triển khai MQTT Rule Engine trong thực tế công nghiệp.
  • Doanh nghiệp vừa và nhỏ (SMEs): Sở hữu giải pháp quản lý điện năng chuyên sâu với chi phí đầu tư ban đầu thấp hơn từ 60-70% so với giải pháp ngoại nhập, giúp minh bạch hóa dòng tiền chi trả cho năng lượng.
  • Nhà nghiên cứu: Mô hình tham chiếu thực nghiệm để kiểm chứng hiệu quả tối ưu lưu trữ của TimescaleDB đối với dữ liệu cảm biến đo lường công nghiệp.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật phần cứng tối thiểu để triển khai Gateway là gì?

Gateway có thể chạy trên bất kỳ vi máy tính nhúng kiến trúc ARM hoặc x86 có tối thiểu 512MB RAM, hỗ trợ cổng UART hoặc cổng USB để gắn module chuyển đổi USB-to-RS485, và hệ điều hành Linux (như Raspberry Pi OS, Ubuntu Server).

2. Hệ thống xử lý thế nào khi xảy ra mất mạng Internet đột ngột?

Dịch vụ tại Gateway sẽ lập tức phát hiện mất kết nối MQTT, tự động chuyển sang chế độ đệm (Offline Buffering) và ghi toàn bộ dữ liệu vào cơ sở dữ liệu SQLite cục bộ. Khi kết nối Internet được khôi phục, tiến trình nền sẽ đồng bộ tuần tự dữ liệu về Server trung tâm mà không gây xung đột hoặc trùng lặp bản ghi.

3. Làm thế nào để tích hợp dữ liệu từ Server vào hệ thống ERP hoặc MES sẵn có của nhà máy?

Server cung cấp chuẩn RESTful API có xác thực thông qua API Key và token JWT. Các hệ thống bên thứ ba chỉ cần gửi request chuẩn HTTPS đến các endpoint /api/v1/metrics/history để trích xuất dữ liệu phục vụ báo cáo quản trị tổng thể.

4. Hệ thống có khả năng mở rộng tối đa bao nhiêu thiết bị đo trên một đường dây RS-485?

Theo tiêu chuẩn RS-485, số lượng thiết bị vật lý tối đa trên một bus nối tiếp là 32 thiết bị (Unit Loads) với chiều dài cáp tối đa 500m - 1200m ở tốc độ truyền 9600 bps. Nếu muốn mở rộng lên đến 128 hoặc 247 thiết bị, cần lắp đặt thêm các bộ lặp tín hiệu RS-485 chuyên dụng (RS-485 Repeaters).

5. Chi phí đầu tư dự tính và thời gian hoàn vốn (ROI) cho một nhà xưởng quy mô vừa là bao nhiêu?

Đối với một xưởng gồm 5 đến 10 tủ điện phân phối, tổng chi phí lắp đặt Gateway và hệ thống server nội bộ dao động từ 15 đến 30 triệu VNĐ (giảm 70% so với hệ thống SCADA truyền thống). Dựa trên khả năng phát hiện tổn thất điện năng và tối ưu hóa biểu giá điện giờ cao điểm/thấp điểm, thời gian thu hồi vốn trung bình ước tính từ 8 đến 14 tháng.

Kết luận

Đề tài "Thiết kế hệ thống thu thập và giám sát dữ liệu điện năng cho Công ty TNHH Thương mại và Kỹ thuật Thái Bình" đã giải quyết triệt để bài toán giám sát năng lượng thời gian thực cho các doanh nghiệp vừa và nhỏ. Bằng việc kết hợp hài hòa giữa giao thức công nghiệp truyền thống (Modbus RTU over RS-485) và ngăn xếp công nghệ hiện đại (MQTT, FastAPI, TimescaleDB, Vue.js), hệ thống không chỉ đạt độ tin cậy và chính xác cao trong môi trường công nghiệp mà còn đem lại giá trị kinh tế thực tiễn to lớn thông qua việc tiết kiệm chi phí đầu tư và nâng cao hiệu quả sử dụng năng lượng.