主頁 / 什麼是IBMS綜合樓宇管理系統？ 什麼是IBMS綜合樓宇管理系統？ IBMS（Integrated Building Management System）綜合樓宇管理系統的職責在於整合層：把大廈內採用不同通訊協議的機電系統對接互通，使它們能交換訊號並協同動作。本文說明BACnet、Modbus等協議的對接方式、空調照明消防門禁的整合實務、數據點清單的編製，以及香港商廈整合工程的界面處理。
整合層的職責：讓不同協議的系統互通 綜合樓宇管理系統（IBMS）處理的核心問題是「協議不通」。大廈內的空調控制器、照明模組、電錶、水泵變頻器、消防警報盤與門禁控制器，往往由不同專業的承辦商安裝，各自採用不同的通訊協議與資料格式。整合層的工作，就是把這些互不相通的系統接上同一個通訊架構，使訊號能夠雙向傳遞。
整合與上層的管理平台屬於不同層次的工作。整合關注的是實體與通訊層面：接線如何走、協議如何轉換、數據點如何對應、控制指令如何下達到設備。這是工程性質的任務，成果是一套能互通的通訊網絡與一份完整的數據點對應表，而非一個好看的介面。
整合層之所以必要，是因為大廈系統之間存在真實的聯動需求。火警訊號要令門禁釋放門鎖、令空調停止送風並啟動排煙、令升降機返回指定樓層；門禁的上班刷卡要令該區空調與照明提前啟動；電力需量接近上限要令非必要負荷順序減載。這些聯動全部跨越不同承辦商的系統邊界，若沒有整合層，只能靠人手操作或各自獨立的硬接線處理。
整合的深度可以有很大差異。最淺的層次是「狀態讀取」：整合系統只讀取各子系統的狀態，不作任何控制。中間層次是「事件聯動」：某個系統的事件觸發另一個系統的預設動作。最深的層次是「集中控制」：整合系統直接下達控制指令，取代部分子系統的原有控制邏輯。深度愈高，效益愈大，但對可靠性與責任劃分的要求亦愈高。
實務上並非所有系統都應深度整合。消防系統受法例規管，其偵測與警報邏輯必須獨立運作，整合只限於單向輸出訊號與必要的聯動輸入，不可讓外部系統干擾其判斷。這種「有意識地限制整合深度」的取捨，是整合設計中的專業判斷。
BACnet 協議的對接方式 BACnet（Building Automation and Control Networks）是樓宇自動化領域使用最廣的開放協議，原為美國供暖、製冷與空調工程師學會制定的標準，其後成為國際標準。空調、通風、照明與能源計量設備普遍支援 BACnet，因此它通常是整合工作的主軸協議。
BACnet 以「物件」的概念組織數據。每個設備在網絡上是一個裝置物件，其內部的每個數據點則是一個物件，常見類型包括模擬輸入、模擬輸出、模擬值、二進位輸入、二進位輸出、二進位值與多狀態值。溫度感應器讀數是模擬輸入，風機啟停指令是二進位輸出，運行模式選擇是多狀態值。整合時必須逐一確認每個物件的類型、實例編號與工程單位。
BACnet/IP 透過以太網絡與 IP 傳輸，是新建大廈的主流做法。優點是可沿用結構化佈線與網絡交換機、頻寬充裕、可跨樓層擴展；需要注意的是子網廣播範圍與跨子網時的路由設定。
BACnet MS/TP 採用雙絞線的串列總線，多用於現場層的控制器與末端裝置。佈線成本低、適合大量末端設備，但總線速率與每段可掛裝置數目有限，分段規劃與終端電阻設定必須正確，否則整段通訊會不穩。
BACnet 網關 當設備只支援其他協議時，可加裝網關轉換為 BACnet。網關會引入額外延遲並成為單點故障，數據點數量亦受授權上限限制，選型時要按實際點數預留餘量。
BACnet 的一致性等級與支援服務差異，是對接時最常遇到的實際障礙。兩台設備同樣聲稱支援 BACnet，但一台支援訂閱變更通知、另一台只支援輪詢讀取，整合方式便完全不同；一台支援排程物件與趨勢紀錄物件，另一台則不支援，相關功能只能在上層實現。因此設備選型階段就應索取協議一致性聲明文件，逐項核對所需服務。
寫入權限的處理需要格外小心。BACnet 的優先權陣列機制決定當多個來源同時寫入同一個輸出點時以哪一個為準，若整合系統以過高的優先權寫入，會令現場的手動操作或安全連鎖失效。實務上整合系統應使用較低的優先權寫入，把高優先權保留給安全與手動控制。
Modbus 與其他協議的處理 Modbus 是工業控制領域歷史悠久的協議，在電錶、變頻器、發電機控制器、不斷電供電系統與冷水機組控制板上極為常見。它的結構簡單、實作門檻低，但功能亦相對原始，整合時需要處理不少細節。
Modbus 只定義四類資料區：線圈、離散輸入、輸入寄存器與保持寄存器，全部以編號定址，本身不帶任何語意。一個保持寄存器的數值究竟代表溫度、電流還是狀態碼，協議本身並無說明，必須依靠設備廠商提供的寄存器對應表。整合工作的實質內容，很大部分就是逐一核對這些對應表。
數值解讀是 Modbus 對接的主要陷阱。一個寄存器只有 16 位元，較大的數值或浮點數需要用兩個寄存器組合，而位元組與字組的排列次序在不同廠商實作中並不一致，順序錯誤會令讀出的數值變成無意義的巨大數字。倍率同樣需要確認：某個寄存器讀出 235，實際可能代表 23.5 攝氏度或 235 伏特，全靠對應表註明的倍率換算。
Modbus RTU 與 Modbus TCP 是兩種常見傳輸形式。RTU 走 RS-485 串列總線，同一條總線上的所有設備必須採用相同的通訊速率、資料位元與同位檢查設定，且每台設備的從站位址不可重複；TCP 走以太網絡，設定較簡單但需要為每台設備分配 IP 位址。舊設備多為 RTU，整合時常需經串列轉網絡設備接入主網絡。
除 BACnet 與 Modbus 之外，大廈中還會遇到其他協議：LonWorks 見於部分較早期的樓宇自動化系統；KNX 常用於照明與遮陽控制；OPC 統一架構多見於需要與工業控制系統交換數據的場合；閉路電視與門禁系統則通常提供各自的軟件開發套件或網絡應用程式介面，而非樓宇自動化協議。整合設計必須先確認每套系統實際可用的介面，而非假設全部都能以同一協議接入。
協議數量愈多，整合的複雜度與日後維護成本便愈高。設計階段若能在設備選型上收斂協議種類，例如規定機電設備一律支援 BACnet/IP，可大幅減少網關數量與對接工作，這比事後補救有效得多。
空調照明消防門禁的整合實務 各套機電系統的整合方式與注意事項並不相同，需要按系統性質分別處理。以下按香港商廈常見的四大類系統說明實務要點。
空調與通風系統 是整合工作量最大的部分，數據點數目通常佔全部的一半以上。典型接入內容包括冷水機組的運行狀態、供回水溫度與負載率、冷凍水泵與冷卻水泵的啟停與故障訊號、空調機組的送回風溫度、風機狀態、冷凍水閥開度、過濾網壓差警示，以及各區域的溫度設定值與實際值。整合後可實現按時間表啟停、按實際負荷調整設定值、以及設備故障即時通知。
照明控制 的整合重點在於分區與場景。大廈的公共區域照明一般按時間表與日光感應控制，辦公樓層則按租戶時間與人員在場情況控制。整合時需要確認照明控制系統的分區劃分是否與其他系統一致——若空調按四個區域劃分而照明按六個區域劃分，聯動邏輯便需要額外的對應處理。
消防系統 的整合必須遵守單向為主的原則。消防警報盤向整合系統輸出火警與故障訊號，通常經無源接點或受監控的通訊介面輸出，令整合系統可觸發其他系統的應變動作；但整合系統不應具備影響消防偵測與警報判斷的寫入權限。門禁在火警時的釋放邏輯亦應以硬接線為主要途徑，通訊介面僅作輔助與狀態回報，確保通訊中斷時釋放功能仍然有效。
門禁系統 的整合價值在於提供「人在哪裡」的資訊。刷卡進出紀錄可用於判斷各樓層的實際使用情況，令空調與照明按實際佔用而非固定時間表運作；亦可支援訪客管理與升降機樓層權限的聯動。整合方式通常是透過門禁軟件提供的應用程式介面或資料庫介面取得事件，而非樓宇自動化協議。此處必須注意個人資料的處理範圍，只取得管理所需的資料。
四類系統以外，升降機狀態、電力計量、水錶、發電機與不斷電供電系統、水浸與漏水偵測亦是常見的整合對象。整合次序一般按「效益高、對接容易」優先，把技術難度高或效益不明確的系統留待後期，避免整個工程被個別難點拖延。
數據點清單與界面劃分 整合工程的成敗，往往不取決於技術難度，而在於文件是否清晰。數據點清單與界面劃分表是整合工程最重要的兩份文件，缺少它們的工程幾乎必然出現爭議與返工。
數據點清單逐項列明每一個需要整合的數據點：所屬系統、實際設備位置、點名稱、數據類型（模擬或數位、讀取或寫入）、工程單位、數值範圍、更新頻率，以及該點由哪一方負責提供。清單應在設計階段編製並經各方確認，作為報價、施工與驗收的共同基準。點數是整合工程的主要計價依據，清單不清則報價無從比較。
由聯動需求反推所需點位 ——先列出希望實現的聯動與監控功能，再逐項推導需要哪些數據點，避免「把所有點都接上」造成點數虛高與成本失控。確認每個點的實際可得性 ——設備規格書聲稱可輸出的點，實際可能需要加購通訊模組或軟件授權，這要在確認清單時逐一核對。明確寫入點的權限與優先權 ——凡涉及控制寫入的點，必須寫明優先權層級與現場手動操作的關係，並在測試時實際驗證安全連鎖不受影響。劃定各承辦商的界面位置 ——註明訊號交接的實體位置（哪一個端子箱、哪一個網絡插座）、由誰提供接線、由誰負責測試，避免現場出現無人負責的中間地帶。編製點對點測試表 ——驗收時逐點核對實際值與整合系統顯示值是否一致、寫入指令是否生效、故障訊號是否正確上報，並保留測試紀錄。界面劃分的爭議多發生在「訊號已輸出但整合系統收不到」的情況。子系統承辦商認為自己已按規格輸出，整合承辦商認為收到的數據不符預期，雙方各執一詞。防止方法是在界面劃分表中明確定義交接點的技術規格：協議版本、數據格式、位址範圍、通訊參數，並要求子系統承辦商提供實際的通訊測試證明，而非僅憑規格書聲稱。
調試階段的時間安排亦需要現實考慮。整合調試必須在各子系統本身已完成調試並穩定運行後才能有效進行，若子系統仍在調整，整合測試會反覆受影響。工程進度表應為整合調試預留獨立時段，並安排各子系統承辦商在該時段派員配合，這在多承辦商的工程中需要業主或總承辦商主動協調。
系統交付後的文件同樣重要：最終版數據點清單、通訊架構圖、各設備的通訊參數設定、網關組態備份與測試紀錄，都應作為交付文件的一部分。日後任何一套子系統更換或升級時，這批文件是判斷影響範圍的唯一依據。
香港商廈整合工程的實際考慮 香港商廈的整合工程有其獨特的環境條件：大廈以高層為主、機房空間緊張、租戶更替頻繁、機電系統的安裝年份往往相差十數年。這些條件直接影響整合方案的設計。
法定計量要求是整合工作的現成基礎。機電工程署《建築物能源效益守則》（BEC 2021）第 7.7.3 條規定整個冷凍水機房、整個熱水機房及全部升降機的供電回路須分別設置計量裝置；第 7.7.2 條則對 200A 至 400A 及 400A 以上的饋線與分主回路分別規定所需的量測項目。這些計量裝置普遍支援 Modbus 或 BACnet 輸出，是整合工程中對接成本最低而管理價值明確的一批數據點。
升降機方面，BEC 2021 第 8.5.3 條要求在垂直運輸需求偏低的時段，同一組升降機中至少一部須進入停泊模式；第 8.5.4 條則要求升降機廂的通風在閒置 2 分鐘後自動關閉、空調在閒置 10 分鐘後自動關閉並在關閉後不早於 5 分鐘才恢復。整合系統讀取升降機狀態與客流資料，有助驗證這些節能控制是否按設計運作。
先做系統盤點與通訊能力調查 ——逐套系統確認品牌、安裝年份、控制器型號與可用通訊介面，並實地檢查是否已預留通訊接線。舊系統的資料常已散失，需要開櫃檢視實物。處理新舊系統並存的現實 ——分階段翻新的大廈常見同類系統有多個世代並存，整合方案要容納多種協議，並在數據模型上把它們統一，否則上層無法一致呈現。安排機房空間與通訊路由 ——整合伺服器、網關與網絡設備需要機櫃空間、供電與散熱；跨樓層的通訊路由要確認現有豎井與線槽是否有餘量，香港商廈的豎井普遍已相當擁擠。協調多承辦商與租戶時段 ——整合接線常需進入機房、電錶房與租戶單位，涉及大廈管理處的工作許可與租戶配合，非辦公時間施工的安排要及早申請。預留擴充餘量 ——租戶更替會帶來新的分區與新的數據點需求，網關授權點數、網絡埠與伺服器容量都應預留餘量，避免每次小改動都要加購硬件。綠建認證方面，BEAM Plus 在能源使用與室內環境質素等範疇均設有評分項目，而持續量測與紀錄是證明表現的基礎。整合層提供的數據是這些紀錄的來源，因此在整合設計時把認證所需的量測項目一併納入數據點清單，比認證階段才補加感應器更為經濟。
總括而言，IBMS 整合工程的技術難點在協議對接，管理難點在界面劃分與多方協調。實際工程涉及機電、電力、消防、保安與網絡多個專業，一般由具大廈系統整合經驗的承辦商統一負責界面協調，並在設計階段就完成數據點清單的確認。