Bối cảnh dự án

Tòa nhà sử dụng hệ thống BMS cũ của hãng A, xuất dữ liệu qua BACnet/IP với hơn 18.000 điểm dữ liệu. Hầu hết các thẻ vẫn ở dạng mã kỹ thuật như “AHU-12-RA-T”. Nhiệm vụ là xây dựng lớp ngữ nghĩa hỗ trợ truy vấn kiểu “tìm cảm biến nhiệt độ đang lỗi trong khu vực có tỷ lệ sử dụng trên 50%”.

Brick và Haystack được lựa chọn vì Brick cung cấp ontology quan hệ còn Haystack hỗ trợ gắn thẻ linh hoạt. Tuy nhiên, hai thư viện gốc thiếu đơn vị đo lường địa phương và thuật ngữ tiếng Việt.

Ngày 1: Làm quen với mô hình ngữ nghĩa tự mô tả

Đọc ontology Brick 1.3 và định nghĩa các lớp brick:Temperature_Sensor cùng các quan hệ brick:isPointOf, brick:feeds. Nhận thấy ontology rõ ràng nhưng việc ánh xạ quan hệ thực tế rất dễ sai lệch vì BMS không cung cấp topology.

Ngày 2: Ánh xạ Brick lên hệ thống BMS hiện tại

Xuất CSV từ BMS và viết script Python sử dụng rdflib để chuyển đổi thành đồ thị Brick. Vấn đề lớn nhất là tên đối tượng BACnet không chuẩn và nhiều thiết bị dùng tiếng Việt viết tắt. Phải tạo bảng ánh xạ thủ công cho khoảng 2.400 điểm.

Ngày 3–4: Kết hợp Haystack và xử lý truy vấn phức hợp

Chuyển sang Haystack 4 để bổ sung thẻ động. Kết hợp hai công cụ: Brick định nghĩa quan hệ cấu trúc, Haystack gắn thẻ linh hoạt. Viết truy vấn SPARQL để lọc cảm biến nhiệt độ lỗi trong khu vực có tỷ lệ sử dụng trên 50%. Kết quả trả về 17 cảm biến chính xác.

Ngày 5–7: Mở rộng dữ liệu tiếng Việt và kiểm tra khả năng mở rộng

Tạo phần mở rộng cho đơn vị đo lường địa phương và nhãn tiếng Việt. Thử nghiệm mở rộng sang hai tầng tiếp theo cho thấy chi phí ánh xạ tăng gần như tuyến tính. Quyết định đóng băng ontology ở mức 80% độ phủ.

Bài học sau 7 ngày

• Brick mạnh về quan hệ nhưng yếu về tính linh hoạt khi BMS thay đổi; Haystack ngược lại.
• Dữ liệu tiếng Việt và đơn vị địa phương bắt buộc phải mở rộng thủ công.
• Thời gian thực tế chủ yếu dành cho làm sạch và duy trì ánh xạ thay vì viết truy vấn ngữ nghĩa.