IBMS · Phạm vi
Phạm vi IBMS — Ma trận hệ thống con, không phải danh sách mong muốn
Một phương pháp thực tế để xác định phạm vi IBMS: ma trận hệ thống con, độ sâu tích hợp thực tế, các loại trừ và tiêu chí nghiệm thu.
Trả lời nhanh
Phạm vi IBMS được xác định bằng một ma trận hệ thống con: với mỗi hệ thống, nêu rõ hệ thống đó được giám sát, điều khiển, tham gia liên động liên hệ thống hay chỉ được báo cáo. Các hệ thống an toàn tính mạng và an ninh thường giữ nguyên bộ điều khiển riêng, IBMS chỉ giám sát trạng thái và sự kiện thay vì phát lệnh.
Phạm vi là một ma trận, không phải danh sách
Một danh sách hệ thống con cho biết những gì được kết nối. Một ma trận cho biết mỗi kết nối được phép làm gì. Dùng hàng cho các hệ thống và cột cho giám sát, điều khiển, xử lý cảnh báo, liên động liên hệ thống và báo cáo. Thêm cột cho đơn vị sở hữu giao diện và kiểm tra nghiệm thu. Ma trận phơi bày các lỗ hổng trước khi chúng trở thành lệnh thay đổi: một hệ thống được đánh dấu để điều khiển nhưng không có giao diện ghi được, hoặc một liên động phụ thuộc vào điểm mà không ai cung cấp. Nó cũng cho người vận hành một bức tranh thực tế về những gì nền tảng sẽ làm và sẽ không làm. Một ma trận không có cột đơn vị sở hữu chỉ là sơ đồ của những ý định. Giữ cột kiểm tra nghiệm thu hiển thị trong các buổi đánh giá thiết kế; nó biến một lời hứa thành một hạng mục bàn giao.
Độ sâu thực tế theo từng hệ thống con
HVAC thường hỗ trợ giám sát và điều khiển đầy đủ. Chiếu sáng có thể hỗ trợ kịch bản và lịch trình, nhưng không phải nhóm đèn nào cũng đáng điều khiển riêng. Đồng hồ năng lượng chỉ giám sát, với độ sâu báo cáo do đồng hồ và cổng kết nối quyết định. Kiểm soát ra vào có thể chia sẻ sự kiện và quyền, trong khi hệ thống kiểm soát ra vào vẫn giữ logic quyết định riêng. Báo cháy chỉ giám sát trạng thái và sự kiện; lệnh vẫn thuộc về hệ thống báo cháy. Thang máy, bãi đỗ xe và phòng khách sạn rất khác nhau. Độ sâu phù hợp là độ sâu mà người vận hành thực sự sẽ dùng, không phải mức tối đa mà giao thức cho phép. Điều khiển phòng khách sạn có thể bao gồm kịch bản và giới hạn năng lượng, trong khi PMS của khách sạn giữ quy trình riêng. Mỗi quyết định về độ sâu cần được biện luận bằng một kịch bản vận hành, không phải bằng danh sách năng lực giao thức.
Những gì nên loại trừ
Hãy loại trừ mọi thứ không thể được hỗ trợ sau bàn giao. Điều đó bao gồm các bộ điều khiển lỗi thời không có giao diện được ghi chép, cổng thông tin của nhà cung cấp yêu cầu tài khoản cá nhân, và các hệ thống mà đường tích hợp duy nhất vượt qua giới hạn an toàn của chúng. Các lệnh an toàn tính mạng nên thuộc về chính hệ thống an toàn tính mạng. Tránh tích hợp một hệ thống con chỉ để hiển thị một giá trị trên bảng điều khiển; giao diện, cổng kết nối và gánh nặng bảo trì sẽ tồn tại lâu hơn sự mới lạ. Một danh sách loại trừ rõ ràng bảo vệ dự án nhiều như một danh sách bao gồm rõ ràng. Mỗi loại trừ cần có lý do và hệ quả, để khách hàng có thể chấp nhận nó một cách có hiểu biết. Nếu một hệ thống con không có giao diện ổn định, một quy trình thủ công được ghi chép thường là câu trả lời trung thực.
Viết bản phát biểu phạm vi
Hãy chuyển ma trận thành một bản phát biểu phạm vi gồm bốn phần: các hạng mục bao gồm, các loại trừ, trách nhiệm giao diện và kiểm tra nghiệm thu. Nêu rõ giao thức, đơn vị sở hữu cổng kết nối, cơ sở đếm điểm và quyền sở hữu dữ liệu. Nêu rõ điều gì xảy ra khi một giao diện không khả dụng. Xác định bài kiểm tra chứng minh từng hàng, và yêu cầu kết quả trong bộ hồ sơ bàn giao. Rà soát bản phát biểu ở mỗi giai đoạn thiết kế, vì phạm vi âm thầm tăng lên qua các câu hỏi tại công trường. Tài liệu cần đủ ngắn để đọc trong một cuộc họp và đủ cụ thể để định giá. Dùng cùng thuật ngữ với hồ sơ mời thầu, để phạm vi có thể được so sánh từng dòng. Khi một câu hỏi làm thay đổi phạm vi, hãy ghi lại thay đổi và chi phí của nó trước khi tiếp tục.
Độ sâu tích hợp IBMS điển hình theo hệ thống con
7 rows| Hệ thống con | Độ sâu điển hình | Ranh giới |
|---|---|---|
| HVAC | Giám sát và điều khiển | Trình tự điều khiển vẫn nằm trong bộ điều khiển DDC |
| Chiếu sáng | Kịch bản, lịch trình và trạng thái | Chiếu sáng sự cố vẫn thuộc hệ thống riêng |
| Đo đếm năng lượng | Giám sát và báo cáo | Độ chính xác của đồng hồ và quyền sở hữu cổng kết nối |
| Kiểm soát ra vào | Sự kiện và quyền | Quyết định ra vào vẫn nằm trong hệ thống kiểm soát ra vào |
| CCTV | Sự kiện và các luồng video được chọn | Quy định về quyền riêng tư và lưu trữ |
| Báo cháy | Chỉ trạng thái và sự kiện | Lệnh vẫn thuộc hệ thống báo cháy |
| Thang máy và bãi đỗ xe | Trạng thái, cảnh báo và tình trạng sẵn sàng | Giao diện nhà cung cấp và giới hạn an toàn |
Hình ảnh dự án
3 images
Câu hỏi thường gặp
01IBMS có nên điều khiển hệ thống báo cháy không?
Không. Báo cháy và các hệ thống an toàn tính mạng khác giữ bộ điều khiển chuyên dụng riêng. IBMS có thể giám sát trạng thái và sự kiện và hiển thị chúng cùng các cảnh báo khác.
02IBMS nên tích hợp bao nhiêu hệ thống con?
Không có con số mục tiêu. Hãy tích hợp những hệ thống hỗ trợ một quyết định mà người vận hành thực sự đưa ra; để phần còn lại ra ngoài cho đến khi xuất hiện một tình huống sử dụng thực tế.
03Có thể bổ sung hệ thống con sau này không?
Có, nếu mô hình dữ liệu, cách đặt tên và mạng được thiết kế cho việc đó. Trang bị thêm một hệ thống con không có tài liệu khó hơn nhiều so với bổ sung một hệ thống có giao diện ổn định.
04Ai sở hữu cổng kết nối?
Chỉ nên có một bên. Bản phát biểu phạm vi cần nêu rõ ai cung cấp, cấu hình, kiểm tra và bảo trì nó, bao gồm cập nhật firmware và thiết bị dự phòng.
05Điều gì chứng minh phạm vi đã đầy đủ?
Một ma trận đã ký với kết quả kiểm tra nghiệm thu cho từng hàng, cùng danh sách các loại trừ được khách hàng và người vận hành đồng ý.
Bước tiếp theo
Hãy mang tòa nhà đến với chúng tôi.
Cho chúng tôi biết loại hình tòa nhà, các hệ thống trong phạm vi và kết quả bạn cần. Chúng tôi sẽ vạch ra con đường ngắn nhất đến một hệ thống vận hành được.