電機技師系統整合：通訊協定不相容前期確認6重點

電機技師系統整合做得好不好，關鍵通常不是設備夠不夠新，而是發包前有沒有先把「通訊協定不相容」的界面問題談清楚，掌握通訊協定不相容解決的邏輯，能大幅降低機電整合工地協調時各家廠商互踢皮球、最後演變成弱電施工問題的機率，以下從電機技師與工地主任最常卡關的 Modbus、ONVIF、RS-485 等通訊協定切入，說明前期界面確認的具體做法。

工地現場最麻煩的狀況，很常不是設備完全不能用，比較常見的是，每一套設備單獨看都正常，每一家廠商也都說自己有做好，可是真的要把系統接起來時，問題才開始浮出來。

▪️空調說可以通訊
▪️電錶說有 Modbus
▪️門禁說可以串接
▪️監視器說支援 ONVIF
▪️中央監控平台說可以整合
▪️弱電廠商說線已經拉好
▪️設備商說規格書都有寫

聽起來都沒錯，可是到了測試階段，中央監控畫面就是讀不到資料，或是讀得到狀態，卻不能控制，或是可以控制，但沒有回饋，更麻煩的是，資料會跳、會延遲、會掉線，最後每一家廠商都說問題不在自己這一段。

這時候最辛苦的，通常就是電機技師和工地主任；工地主任被進度追著跑，電機技師要協調機電、弱電、設備商、監控平台和業主，每一家都說自己沒問題，但整個系統就是串不起來，這也是很多機電整合案最容易拖到後期的原因，不是沒有設備，不是沒有施工，也不是現場沒有人處理，而是前面沒有先把「系統之間到底要怎麼說話」講清楚。

電機技師最怕的，不是設備多，而是界面沒有先講清楚

現在很多建築案都會談智慧化、中央監控、能源管理、遠端維護，這些方向都很好，但一進工地，就會發現每一套設備都有自己的邏輯；空調有自己的控制器，電力監測有自己的電錶，照明有自己的控制系統，門禁有自己的管理平台，監視器有自己的影像系統，停車場有自己的辨識與收費系統。

單獨看，每一套都能做，問題是，業主最後要的通常不是「每一套都能獨立運作」，業主要的是集中管理、異常提醒、一個畫面看到設備狀態，以及某個事件發生後，其他系統能跟著動作。

這就不只是施工問題，而是系統整合問題，對電機技師來說，最重要的不是自己去懂每一種設備的程式細節，而是前期先把界面切清楚，誰提供資料？誰接收資料？誰負責轉換？誰負責測試？誰負責最後的整合結果？這些沒有講清楚，後面一定很難收。

通訊協定不相容，白話說就是設備聽不懂彼此的話

通訊協定這個詞聽起來很技術，但用工地現場的話來說，其實就是：設備之間說話的規則不一樣。

• A 設備講的是 BACnet。
• B 平台比較習慣接 Modbus。
• C 設備只有 RS-485 介面。
• D 系統只給 API。

監視器說有 ONVIF，但實際可能只開放影像，不一定開放事件或控制，有些設備只給乾接點，只能知道開或關，沒辦法提供更多資料。

這時候不是線拉到就好，線拉到了，只是有路可以走，資料能不能讀、能不能判斷、能不能控制，還要看協定、格式、點位、權限和設備本身是否真的開放。

很多現場會卡在這裡，大家以為「有通訊介面」就等於「可以整合」，但實際上，中間還差很多細節。

能不能讀資料？
資料代表什麼意思？
多久更新一次？
能不能寫入控制？
控制後有沒有回饋？
資料掉線時有沒有告警？
需不需要授權？
需不需要通訊閘道器？

這些才是會影響後期驗收的地方。

Modbus 是什麼？為什麼電錶、空調、泵浦很常遇到？

Modbus 是工業設備很常見的通訊協定，在工地現場，它常出現在電錶、空調設備、PLC、泵浦、環境感測器、發電機、UPS 和能源監測設備裡，可以把 Modbus 想成設備裡有很多「資料格子」。

每一格可能代表一個數值或狀態，例如電壓、電流、用電量、溫度、運轉狀態或異常訊號。中央監控平台要做的，就是到正確的位置讀資料；問題也在這裡，如果設備商沒有提供完整的暫存器表，平台就不知道要讀哪一格，如果倍率沒有寫清楚，讀出來的數字可能會差十倍、百倍，如果資料型態沒有寫清楚，平台也可能把數字解讀錯，更常見的是，設備只開放讀取，沒有開放寫入，這時中央監控平台就只能看，不能控制。

類型	白話說明	現場要注意
Modbus RTU	常走 RS-485 線路，比較常見於傳統工控設備	站號、通訊速率、線路、終端電阻
Modbus TCP	走網路線，透過 IP 通訊	IP、Port、防火牆、網段、連線穩定性

所以設備商說「我們有 Modbus」時，不能只停在這句話。最好再追問：

✔️是 Modbus RTU 還是 Modbus TCP？
✔️暫存器表有沒有？
✔️倍率和單位有沒有寫？
✔️哪些點位可以讀？
✔️哪些點位可以控制？
✔️誰配合現場測試？

這幾句如果前期沒有問，後面中央監控讀不到資料時，就很容易變成現場互相等。

ONVIF 是什麼？為什麼監視器說支援，還是可能串不起來？

ONVIF 常見在 IP 攝影機、NVR 和影像監控平台之間。

白話一點說，它像是一套影像設備之間的共同溝通規則。有了 ONVIF，不同品牌的攝影機和影像平台，比較有機會互相串接，但現場最常見的誤會是：以為監視器寫支援 ONVIF，就代表所有功能都能被整合；實際上不一定，有些攝影機支援 ONVIF，只是可以讓平台取得即時影像，至於事件告警、移動偵測、錄影調閱、雲台控制、智慧分析，不一定全部開放。

有些功能還是要靠原廠平台，有些需要另外設定帳號權限，有些甚至要看支援的是哪一種 ONVIF Profile，對工地現場來說，不一定要把所有 Profile 都背起來，但至少要知道一件事：ONVIF 不是一句「支援」就結束，而是要確認支援到什麼功能。

如果業主要的是「門禁異常時跳出對應攝影機畫面」、「警報發生時自動帶出現場影像」、「中央平台可以集中看多品牌攝影機」，那就要先確認影像、事件、錄影、權限和串流格式，不然後期一定會卡。

RS-485 也要注意：它是路，不一定是語言

很多現場會把 RS-485 和 Modbus 混在一起講，但嚴格說，RS-485 比較像是通訊用的道路，Modbus 才比較像設備之間說話的規則。有 RS-485，不代表資料就一定能被讀懂；線接上了，不代表平台就知道資料代表什麼；設備有反應，不代表點位就定義完整，所以現場看到 RS-485，不要只確認線有沒有拉，還要確認上面跑的是不是 Modbus RTU、站號是多少、通訊速率是多少、資料位址在哪、終端電阻有沒有處理，多台設備串接時順序怎麼排，否則很容易出現一種狀況：線都在，設備也亮，但資料就是讀不到。

規格書只寫「可整合」，通常不夠

很多工程規格書都會寫：

✅需支援中央監控整合
✅需提供開放通訊協定
✅需可與第三方系統串接
✅需支援 BACnet 或 Modbus
✅監視器需支援 ONVIF

方向沒有錯，但對工地現場來說，這樣常常不夠，因為「可整合」三個字太模糊了。

🧑🏻‍💼設備商可以說：「我有支援協定。」
🧑🏻‍💼平台商可以說：「但你沒有提供完整點位。」
🧑🏻‍💼弱電商可以說：「線路已經完成，通訊不是我的責任。」
🧑🏻‍💼原廠可以說：「進階功能要另外授權。」
🧑🏻‍💼業主最後只會問：「那為什麼畫面還是沒有資料？」

所以前期如果只寫可整合，後期就很容易變成各說各話，比較好的做法，是把整合需求寫到可以被檢查、可以被測試、可以被驗收。

不只是寫「支援 Modbus」，而是要確認是 Modbus TCP 還是 Modbus RTU。
不只是寫「支援 BACnet」，而是要確認是 BACnet/IP 還是 BACnet MS/TP。
不只是寫「支援 ONVIF」，而是要確認是只支援影像，還是事件、錄影、控制也能串接。

寫得越清楚，後面越少吵架；寫得不清楚，多半到最後都會變成棘手的弱電施工問題。

點位表不是小附件，它會決定整合能不能做下去

很多現場會把點位表當成附屬文件，但做過整合的人都知道，點位表其實是整個整合案的骨架。

點位表如果不清楚，中央監控平台就不知道要讀什麼。點位表如果不完整，畫面就做不完整，點位表如果資料型態沒寫，讀出來的數值可能會錯。點位表如果沒有異常條件，告警就很難定義，更重要的是，點位表如果沒標示可不可控制，驗收時一定會有爭議。

欄位	為什麼重要
設備名稱與位置	避免平台畫面和現場設備對不起來
點位代號	讓整合平台知道要讀哪一個資料
通訊位址	例如 Modbus 暫存器、BACnet 物件
資料型態	避免數值讀錯、倍率錯、單位錯
讀取或控制	分清楚只能看，還是可以下指令
正常範圍	用來判斷資料是否異常
告警條件	決定什麼狀況要跳通知
責任廠商	出問題時知道該找誰
測試方式	驗收時不只靠口頭說明

點位表越完整，整合越順；點位表越模糊，現場就越容易靠猜。 而工地最怕的，就是靠猜做整合。

佳實實際案例：宜蘭轉運站不是只裝設備，而是把多系統整合到可以管理

這種問題在公共場域特別明顯，以佳實系統整合的「宜蘭轉運站中央監控與弱電整合」案例來說，這不是單純裝幾台監視器，也不是只做一套廣播或門禁。宜蘭轉運站在擴建後，場域裡有售票候車空間、辦公區、地下自動化停車場，也牽涉到電力、給排水、消防、停車、CCTV、門禁、緊急求救、CO2 偵測與排風等系統。佳實案例頁也提到，轉運站每年承載超過 300 萬人次，因此管理重點不只是設備能不能運作，而是能不能讓管理端即時看到狀態、收到告警，並在必要時做出連動反應。

這個案例很適合放在這篇文章裡，因為它剛好說明一件事：中央監控不是把畫面集中起來就好，而是要把設備、點位、告警、連動、操作介面和維護責任一起想清楚。

像地下停車場的 CO2 偵測，如果濃度過高，不能只是畫面跳一個數字，還要能讓監控中心示警，並連動排風機啟動。CCTV、門禁、緊急求救、停管系統，也不能各做各的，否則管理人員還是要在多套系統之間來回切換。佳實在該案中將電力、給排水、汙水泵浦、CO2 偵測、導流風機、排風機、CCTV、門禁偵測、緊急求救和智慧停管等項目整合到中央監控管理邏輯中，重點就是讓場域變得比較好看、好管、好維護。

這也回到工地現場最實際的問題；整合做得好，管理端看到的是一個清楚的系統，整合沒先講清楚，現場看到的就是一堆各自正常、但接不起來的設備。

最容易卡住的，通常是跨系統連動

如果每套設備各自使用，問題通常比較少，但只要牽涉連動，事情就會變複雜，例如：門禁刷卡異常時，要不要跳出監視器畫面？CO2 濃度過高時，排風系統要不要自動啟動？火警發生時，廣播和門禁要不要連動？停車場車牌辨識後，柵欄機、剩餘車位和收費系統要不要同步？電力需量過高時，要不要通知管理人員或調整設備運轉？

這些需求在會議上講起來很順，但真的要做，就要回到很具體的問題。

哪個系統發出訊號？
哪個系統接收訊號？
中間用什麼協定？
資料格式是什麼？
延遲能不能接受？
失敗時怎麼處理？
誰負責測試？
誰負責維護？

如果這些沒有先講，後面就會變成每家廠商都說自己那一段沒問題，但整個流程就是跑不起來。

工地主任要進度，電機技師要先做好機電整合工地協調

工地主任最怕卡工，不是不想等，而是等下去會影響後面的工項、驗收和交屋，某個系統不能測，中央監控畫面就不能收。某條通訊線沒預留，天花封板後又要補。某個設備資料不開放，平台畫面就只能空著。某個廠商文件沒交，其他廠商就只能等，電機技師在這裡的角色很重要，因為電機技師通常比較能看懂機電、弱電、監控平台和現場施工之間的關係，如果前期可以先把界面拆開，工地主任後面會輕鬆很多。

▫️設備端要交什麼資料
▫️弱電端要拉什麼線
▫️平台端要做什麼畫面
▫️原廠要不要開授權
▫️整合測試什麼時候做
▫️驗收時看哪幾個狀態
▫️異常發生時誰負責確認

這些不是 paperwork 而已。它會直接影響現場能不能往下走。

發包前先做一張整合界面表，比後面開十次會有用

有些爭議，其實一開始做一張表就能少很多，這張表不用一開始就寫得很複雜，但至少要把每套系統要整合什麼、用什麼方式、誰負責、缺什麼資料先列出來。

系統	要整合什麼	可能的通訊方式	前期要先確認
空調	運轉狀態、溫度、告警、啟停	BACnet、Modbus	點位表、控制權限、更新頻率
電力監測	電壓、電流、用電量、需量	Modbus TCP / RTU	暫存器表、倍率、資料單位
門禁	門狀態、進出事件、異常	API、TCP/IP、乾接點	是否即時、是否開放事件
CCTV	影像、事件、錄影調閱	ONVIF、RTSP、原廠平台	支援範圍、權限、串流格式
停車系統	車牌、柵欄、剩餘車位	API、TCP/IP	資料格式、連動流程
廣播	分區、緊急訊號、優先權	TCP/IP、乾接點	消防界面、控制邏輯

這張表的目的不是增加文件量，而是讓大家在施工前先知道：

誰要交資料？
誰要接資料？
誰負責轉換？
誰負責測試？
最後用什麼標準驗收？

這些先講清楚，後面才不會每次都從頭吵。

系統整合廠商不是最後來救火的人

有些案子會等設備裝完、線也拉完，才請系統整合廠商進場，這樣不是不行，但風險很高。

因為到了那個時間點，很多東西已經固定了，設備型號定了，管線走完了，天花封了，點位表可能還沒整理，原廠授權還沒談，通訊介面可能不符合平台需求，驗收標準也還沒講清楚，這時候整合廠商進場，很多時候不是在整合，而是在補破網。

比較好的做法，是在發包前或施工前就讓系統整合團隊看一次，他們可以先幫忙檢查哪些設備協定可能不一致，哪些系統需要通訊閘道器，哪些點位表需要補，哪些資料只能讀、不能控制，哪些功能要原廠授權，哪些通訊線要提前預留，哪些項目要寫進驗收條件，好的系統整合廠商，不只是會接設備。更重要的是，他們知道哪裡以後會卡。

整合失敗，通常不是單一技術問題

現場整合失敗，表面上看是通訊問題，但實際上常常是三件事混在一起。

第一、需求沒有翻成資料：業主說要智慧化，設計說要中央監控，廠商說可以整合。但沒有人把它變成具體資料需求。

到底要看什麼？
要控制什麼？
要記錄什麼？
要告警什麼？
要保留多久？
要用什麼方式呈現？

第二、界面沒有切清楚：設備端、平台端、弱電端、原廠端、施工端，每一段誰負責沒有講明白。

第三、驗收標準太模糊：只寫「測試正常」，後面很難判斷。

正常是什麼？畫面有數字就算正常嗎？數字正不正確要不要驗？告警有沒有測？控制有沒有測？斷線有沒有測？恢復連線有沒有測？這些沒有寫清楚，驗收時一定會卡。

什麼案子一定要提早談系統整合？

不是每個案子都需要很複雜的整合，但只要出現下面幾種情況‵，建議不要等到後期才處理。

✅如果業主要中央監控，就要提早談，因為不同設備最後要集中到同一個平台，協定、點位、畫面、權限、告警都要先定。

✅如果現場有很多設備廠商，也要提早談。廠商越多，界面越容易模糊。

✅如果有跨系統連動，更要提早談，像門禁連監控、火警連廣播、CO2 連排風、停車連車位顯示，這些都不是設備裝好才來討論就能順利收尾。

✅如果資料要做報表，也要提早談，用電、環境、設備狀態、異常紀錄，只要要長期保存，就不能只看當下有沒有通。

✅如果未來會擴充，也要提早談，一開始架構太死，後面每加一套設備都會很痛苦。

結論

電機技師不可能替每一家廠商寫通訊程式，也不可能在現場替所有設備商解協定問題，但電機技師可以在前期先把規則拉出來，包含以下：

▪️哪些系統要整合
▪️整合到什麼程度
▪️使用什麼通訊方式
▪️誰提供點位表
▪️誰提供通訊文件
▪️誰負責轉換
▪️誰配合測試
▪️誰負責最後驗收

這些如果前期沒有講，後面就會變成工地現場的協調問題。

通訊協定不相容，看起來是技術問題，但在工地上，它很快就會變成進度問題、責任問題、驗收問題和追加預算問題，所以電機技師做系統整合，重點不是自己懂所有設備，而是讓每個系統在進場前，就知道自己要怎麼和別人接起來。

需要先做機電與弱電整合檢查嗎？

如果你的案子已經有多系統、多廠商、多平台，建議在施工前先做一次整合檢查，先確認哪些設備要被整合，哪些協定已經確定，哪些點位表還沒交，哪些資料只能讀，哪些可以控制，哪些需要通訊閘道器，哪些功能需要原廠授權，哪些項目要列入整合驗收，哪些責任邊界現在還不清楚，很多工地問題不是現場才發生，只是前期沒有先把它攤開。