直接回答

聯動該本地做還是等平台做？答案是：越致命的動作越靠近設備本地。毫秒級的短路與人身保護必須硬接線執行，秒級的減載排風交給本地控制器，分鐘級的通知工單才交給平台——網路只承擔優化與可視化，不承擔保命。

某園區把配電櫃的變壓器過流跳閘做成了「平台遠端指令」：值班室點擊「分閘」，平台下發指令給閘道，閘道再驅動斷路器。聽起來很智慧，直到一次施工挖斷光纖——通訊中斷的 3 分鐘裡，一台變壓器恰好內部短路，本地沒有任何動作，全靠上游總開關越級跳閘，變壓器燒損過半。復盤結論只有一句：保命動作不能等平台。

因為：

  • 毫秒級動作必須本地硬接線：保護繼電器固有動作時間 5~20ms，斷路器全開斷 40~80ms，網路根本追不上；
  • 秒級動作交給本地控制器：減載、排風、消防聯動 1~5s 內完成，靠閘道/PLC 本地邏輯，不依賴通訊；
  • 分鐘級動作才交給平台：通知、工單、統計、優化，斷網半小時也無所謂；
  • 致命動作永遠最高優先級：任何遠端指令都不得覆蓋本地保護。

關鍵認知：聯動不是「能不能做」，而是「該在哪一層做」。把關鍵聯動放到網路層，等於把安全冗餘建立在最不穩定的環節上。

某港口配電房做過一次「雙保險」改造：把所有跳閘都做了本地硬接線聯鎖，同時把動作記錄上送平台。半年後一次雷擊導致通訊交換機燒毀，本地保護依然 80ms 內完成開斷——值班室第二天才看到告警，但設備毫髮無損。

一、三層聯動：響應速度決定執行位置

聯動的核心約束是時間。從事件發生到動作完成，可用時間決定了該用哪一層執行。

第一層：本地硬接線（毫秒級）

  • 保護繼電器固有動作時間 5~20ms，加斷路器機構開斷 30~60ms，全鏈路 40~80ms；
  • 典型動作：短路跳閘、人身安全（急停、弧光保護）、母線失壓聯跳；
  • 實現方式：電流/電壓/弧光訊號 → 繼電器 → 硬接線直接驅動分閘迴路，全程無軟體、無通訊、無處理器參與；
  • 可靠性來源：無源、無程式、無依賴——即使控制電源消失，跳閘迴路靠電容儲能或機械保持仍能動作。

第二層：本地控制器邏輯（秒級）

  • PLC/邊緣閘道掃描週期 10~100ms，加上判斷與出口延時，動作在 1~5s 內完成；
  • 典型動作：過載減載、排風啟動、電容器自動投切、備自投切換；
  • 實現方式：控制器本地程式判斷，出口繼電器驅動，同一台設備內閉環；
  • 可靠性來源：不依賴上位機與網路，單機自治。

第三層：平台遠端（分鐘級）

  • 區域網路指令往返 10~50ms，跨廠區 50~200ms，雲平台 200ms~2s，加上人為確認，實際動作分鐘級；
  • 典型動作：遠端分合閘（人工確認後）、參數下發、聯動預案切換、工單派發；
  • 實現方式：平台 → 閘道 → 設備，鏈路長、環節多；
  • 定位：優化與可視化，不是保護。

三層之間的分工原則：可用時間越短的動作，越往設備本地放。能用硬接線絕不用軟體，能本地絕不上平台。

二、為什麼硬接線不能被軟體替代

很多人覺得「繼電器邏輯太落後，用程式更靈活」。這是把可靠性當成了靈活性。

硬接線的四個不可替代特性：

  1. 無軟體故障面：沒有程式就沒有死循環、沒有記憶體洩漏、沒有版本升級出 bug；
  2. 無通訊依賴：訊號從比流器到繼電器到分閘線圈，全程銅線，斷網斷電都不影響（前提是電源獨立）；
  3. 確定性時延：繼電器 5~20ms 是物理特性，可驗收、可複測；軟體時延受負載和調度影響，波動大；
  4. 可現場驗證：用測試按鈕就能驗證整條迴路，不需要依賴任何平台線上。

軟體的適用邊界：靈活邏輯（多條件組合、時序調整、趨勢判斷）屬於控制器與平台。但「最終動作出口」必須有一道硬接線兜底——程式判斷再聰明，出口繼電器和分閘迴路必須物理存在。

典型錯誤：把「過流跳閘」做成純軟體邏輯（閘道讀電流→判斷→發指令給斷路器），控制器當機或通訊斷，跳閘就沒了。正確做法：保護繼電器硬接線跳閘為主，軟體記錄和告警為輔。

三、通訊中斷時的降級行為

聯動方案必須回答一個問題：通訊斷了，系統怎麼辦？

正常狀態：三層各司其職，平台即時監控、下發優化指令、推送告警。

通訊中斷狀態（降級行為）：

  • 第一層（硬接線）：完全不受影響，繼續毫秒級保護；
  • 第二層（本地邏輯）：繼續執行本地程式——減載、備自投、排風照常，只是不向平台上報；
  • 第三層（平台）：所有遠端指令失效，平台側顯示「通訊中斷」；
  • 關鍵：降級不是「癱瘓」，而是回到「本地自治」——這正是分層設計的目的。

降級設計的三條硬規則：

  1. 通訊中斷時，本地邏輯必須維持原有保護與聯鎖功能，不得因「收不到平台指令」而停止動作；
  2. 任何依賴平台的聯動（遠端分合閘、預案切換）在中斷期間必須閉鎖，防止「半路指令」誤動；
  3. 恢復通訊後，狀態自動同步，但不自動執行中斷期間積壓的指令——由人工確認後執行，防止補刀誤動。

案例：某資料中心 UPS 供電的聯動迴路，通訊交換機故障 40 分鐘，本地備自投邏輯照常完成 3 次切換，機房無感；恢復後平台自動同步了 40 分鐘的狀態曲線，值班人員核對無異常。如果當時把備自投也做成平台指令，這 40 分鐘就是災難窗口。

四、本地邏輯與平台指令的優先級

優先級不是「誰說了算」，而是誰更接近安全底線。

優先級從高到低：

  1. 本地保護（繼電器硬接線）：最高，任何指令不得覆蓋；
  2. 本地聯鎖（控制器邏輯）：次高，平台指令不得越過它執行；
  3. 平台聯動（遠端指令）：僅在本地邏輯允許的範圍內生效；
  4. 通知與記錄：最低，只影響「人知不知道」。

衝突處理原則：

  • 平台下發「合閘」，本地邏輯判斷「母線有壓、接地訊號存在」→ 拒絕執行並上報；
  • 平台下發「減載」，本地邏輯判斷「該饋線正在帶重要負荷」→ 提示人工確認；
  • 平台下發「退出保護」→ 本地必須拒絕，除非有雙重授權且現場確認。

常見錯誤：把平台遠端指令的優先級設計得高於本地聯鎖，比如「遠端急停」直接繞過本地安全條件。結果一次誤操作，平台一個指令直接跳掉整條母線。正確做法：遠端指令必須經過本地邏輯的安全校驗，本地安全條件是遠端指令的「門衛」，不是「擺設」。

五、聯動迴路的電源獨立性設計

聯動執行得再快，電源沒了全是空談。電源獨立性是聯動可靠性的最後一道物理保障。

三層電源設計：

  1. 主控電源：控制母線 DC 220V / DC 110V，負責控制器、閘道、指示；
  2. 聯動執行電源：獨立 24V DC 或與保護迴路共用控制母線，負責出口繼電器、聯動線圈——關鍵：聯動電源不得與通訊設備共用同一路，通訊交換機燒毀不應影響聯動出口；
  3. 後備電源：UPS / 電池，後備時間至少 30 分鐘（消防聯動等關鍵迴路按規範更長），保證通訊中斷+市電失壓時本地邏輯仍有電可動。

防跳與保持：斷路器分閘線圈按「短時通電+防跳」設計，防止合分反覆；聯鎖迴路加保持繼電器，動作後保持狀態，避免電源抖動導致誤復歸。

案例：某工廠聯動改造，把減載出口繼電器和通訊交換機接在同一路 24V 電源。一次突波燒了交換機電源模組，減載聯動同時失電，兩台馬達過載未減載燒毀。改造後聯動電源獨立，交換機隨便壞，減載照常。

六、產品怎麼落地：數位化電氣智慧監管系統的分層實現

微物聯的數位化電氣智慧監管系統正是按「三層聯動」架構落地：

  • 本地保護與硬接線聯鎖：作為獨立物理層，不依賴平台，保障毫秒級動作；
  • 邊緣運算閘道（FEXLINK 邊緣運算閘道）：承擔秒級本地邏輯——減載、備自投判斷、排風聯動，斷網自治；
  • 千知告警引擎：承擔分鐘級通知與工單——分級推送、閉環跟蹤，通訊恢復後自動補發；
  • 天衍引擎（趨勢預警演算法）：提前發現隱患，把「突發故障」變成「計劃處理」——給本地保護爭取時間，而不是替代本地保護。

設計原則一句話：平台讓聯動更聰明，本地讓聯動更可靠。 天衍發現趨勢、千知負責通知、閘道執行本地動作、硬接線兜底保命——四層各司其職，任何一層失效，其餘照常。

七、現場常見錯誤

  1. 把跳閘做成平台軟體指令：通訊斷就失效。後果：故障時保護不動作，設備燒損、越級跳閘擴大停電。正確做法：保護繼電器硬接線跳閘，平台只記錄。
  2. 聯動迴路與主控共用電源：主控故障或電源突波，聯動全癱。後果：減載、備自投全部失電失效。正確做法：聯動執行電源獨立，後備 UPS 至少 30 分鐘。
  3. 通訊中斷無降級策略：預設「等平台指令」。後果：中斷窗口內所有聯動停擺，等於裸奔。正確做法：預先定義降級行為，本地自治兜底。
  4. 遠端指令優先級高於本地聯鎖：平台一個誤指令繞過安全條件。後果：誤跳母線、誤並網、人身風險。正確做法：遠端指令必須過本地安全校驗。
  5. 聯動迴路無防跳設計：合分反覆，機構磨損、系統振盪。正確做法：分閘迴路加防跳繼電器。

適用範圍與限制

本文討論工業/建築配電的聯動分層設計原則，適用於低壓至中壓配電系統。具體繼電器選型、迴路參數以工程設計和設備手冊為準；消防聯動等受強制規範約束的迴路，必須滿足 GB 50116 等相關要求；案例均已脫敏（某園區/某港口/某資料中心），不指向任何具體客戶。