Phạm vi IBMS thất bại theo hai hướng: hoặc quá mơ hồ đến mức mỗi nhà cung cấp báo giá một dự án khác nhau, hoặc quá quy định chi tiết đến mức mô tả một sản phẩm thay vì một kết quả. Một phạm vi có thể triển khai nằm giữa hai thái cực đó.
Bắt đầu từ kết quả
Hãy ghi rõ tòa nhà phải làm gì: người vận hành cần ra những quyết định nào, cảnh báo nào phải đến tay vai trò nào, báo cáo nào phải tồn tại khi bàn giao. Kết quả là phép thử cho mọi dòng tiếp theo.
Danh mục hệ thống
Liệt kê mọi hệ thống con trong phạm vi, nhà cung cấp, giao diện và người sở hữu dữ liệu. Nếu một giao diện chưa rõ, hãy biến việc đánh giá thành hạng mục bàn giao thay vì giả định nó tồn tại.
| Hạng mục | Nội dung cần nêu | Chủ sở hữu |
|---|---|---|
| HVAC / hệ thống kỹ thuật | BACnet/IP hoặc Modbus, danh sách điểm, trách nhiệm cổng kết nối | Nhà cung cấp BMS |
| Kiểm soát ra vào | API hoặc OSDP/Wiegand, danh sách sự kiện, trạng thái cửa | Nhà cung cấp kiểm soát ra vào |
| CCTV | ONVIF/RTSP hoặc API của VMS, sơ đồ camera, liên kết sự kiện | Nhà cung cấp VMS |
| Đồng hồ đo năng lượng | Modbus, xung hoặc API của đơn vị cấp điện, chu kỳ và đơn vị | Nhà cung cấp thiết bị đo |
| PMS khách sạn | ODBC hoặc API, sự kiện nhận/trả phòng, trạng thái phòng | Nhà cung cấp PMS |
| Báo cháy | Tiếp điểm khô hoặc đầu vào giám sát; tủ báo cháy giữ quyền quyết định | Nhà thầu phòng cháy |
Ma trận giao diện
Ma trận là trang hữu ích nhất trong phạm vi. Với mỗi hệ thống con, nêu giao diện vật lý, giao thức, hướng dữ liệu, số điểm và ai kiểm thử kết nối. Nếu hai nhà cung cấp dùng chung một giao diện, hãy nêu rõ bên nào sở hữu cổng kết nối.
Bảng điểm
Bảng điểm xác định mọi điểm, địa chỉ, dải giá trị, đơn vị, giới hạn cảnh báo và quy ước đặt tên. Đây không phải chi tiết chạy thử và nghiệm thu. Không có bảng điểm, đồ họa, cảnh báo và xu hướng không thể được kiểm thử nhất quán.
Triết lý cảnh báo
Xác định các lớp cảnh báo, mức ưu tiên, định tuyến và leo thang. Nêu rõ cảnh báo nào bị ức chế trong quá trình bảo trì và ai có thể xác nhận. Một IBMS với 4.000 cảnh báo không phân loại không phải là bức tranh vận hành; đó là nhiễu.
Kiểm thử nghiệm thu
- Xác minh từng điểm đối chiếu với bảng điểm.
- Sinh cảnh báo, định tuyến và xác nhận.
- Từng liên động giữa các hệ thống, được kiểm thử từ sự kiện kích hoạt.
- Độ chính xác của xu hướng và báo cáo trong một khoảng thời gian đã thống nhất.
- Chuyển đổi dự phòng: điều gì xảy ra khi mạng hoặc một bộ điều khiển không khả dụng.
Một phạm vi không thể kiểm thử không phải là phạm vi; đó là một hy vọng. Hãy viết bài kiểm thử trước khi viết yêu cầu.
Những gì nên để ngoài
Không đặc tả mô hình sản phẩm trừ khi dự án thực sự cần. Hãy đặc tả kết quả, giao diện, mô hình dữ liệu và các bài kiểm thử nghiệm thu. Điều đó để lại không gian cho đơn vị tích hợp đề xuất giải pháp phù hợp với tòa nhà.
Kết luận
Một phạm vi IBMS tốt là một tập hợp ranh giới: hệ thống, giao diện, điểm, cảnh báo, kiểm thử và bàn giao. Làm đúng những điều đó, và cuộc trao đổi thương mại sẽ xoay quanh giá trị thay vì sự mơ hồ.
