如何為既有設備漸進式升級
大多數已經運營多年的工廠而言，同時存在新世代設備、過渡世代設備與 Legacy / Brownfield 舊設備。部分設備支援 Ethernet、OPC UA、SECS/GEM 或 MES 介面；部分仍仰賴 RS-232、RS-485、舊 PLC、專有通訊卡、CSV 匯出，甚至只能從 HMI 畫面取得狀態。在半導體或 PCB 廠的整合瓶頸，通常是資料可取得性、語意、時間基準、通訊方式與維護責任不一致。因此，如何為工廠設備數位化，先從判斷設備的製程價值，到從風險管控方式以取得所需資訊。全面汰換只是其中一個選項。
工廠設備數位化為什麼不宜從全面換機開始？
全面換機的成本不會只有設備採購這件事！
新機進廠後，企業要處理安裝、試車、參數設定、Recipe 移轉、MES 串接、品質確認、人員訓練，以及後續驗收。對於具備高精度、高良率或長時間連續生產的設備，還要考慮停機窗口與重新驗證。光是以上零零種種的流程，對於企業來說已是一大筆巨量的隱型成本。
以半導體先進製程為例，則限制更多，當成熟設備已經過長期的製程調校，軟硬體版本、控制程式與製程條件彼此綁定。若只是為了設備聯網，就直接在既有 IPC 或 HMI 上安裝 Agent、更新 OS、加入防毒軟體或修改網路設定，勢必影響到即時控制、驅動程式、設備認證與穩定性。再者，受驗證但老舊的 Windows 或 Linux 系統，不宜任意安裝遠端代理或更新套件；遠端與設備管理需要同時考量資安、控制權及設備驗證。
對 24 小時不間斷運轉的工廠而言，停機本身就是風險。設備還能生產時，老闆也不會因為「資料取得不易」就接受整機汰新。這也是既有設備升級須取採分層策略的原因。
老舊 PLC、HMI 仍可運行，為何仍需列入風險控管？
「現在還可以運作的設備」不代表未來仍可長期維護。
Legacy 設備常見的問題包括 PLC CPU、I/O、HMI、工業電腦、通訊卡、Servo 或電源模組停產。部分原廠已停止支援；程式備份、授權與控制說明也可能不完整。區隔一般 Legacy 舊設備與高風險舊設備。後者除了使用老舊控制器或作業系統，還有備品議題、無完整備份、無原廠支援、單點故障或無法復原等條件。一台運作了20年以上或的高單價且穩定的設備，如果製程能力足夠、備份與備品完整，建議外掛 Gateway；較新的設備若高度封閉且原廠已停止支援，反而可能具有更高的營運風險。
設備主管需要管理 Obsolescence，也就是零件與平台淘汰風險，而非等設備在故障繁複發生後再評估是否升級。盤點內容至少應包括 PLC、HMI、IPC、OS、Firmware、Protocol、備品、程式備份與設備 Owner。
不同世代的新舊設備，取得資料的差異？
新世代設備的資料通常已被設計成產品功能的一部分。
以半導體設備為例，先進設備可透過 HSMS、SECS-II、GEM、GEM300 或 EDA／Interface A 提供設備事件、Alarm、Recipe、Status Variable 與高頻製程資料。PCB 新型鑽孔、成型、LDI、AOI 與濕製程設備，也逐步增加 Ethernet、MES 通訊、板件追蹤與即時資料上傳能力。
那麼，舊設備的情況？
成熟製程或老舊 PCB 獨立機可能只能透過 Serial、PLC register、Vendor-specific protocol、CSV、USB 或 HMI 手抄的方式取得資訊。即使同品牌、同年代的 PLC，也可能因選配不同而具有不同通訊能力。
這會形成幾種典型的 PLC 資料擷取方式：
較新的控制器可直接透過 OPC UA、Modbus TCP 或標準工業 Ethernet 讀取。過渡世代的設備需要 OPC Server、Vendor Driver 或通訊轉換器。只有 RS-232／485 的設備，可以評估 Serial Gateway。完全封閉的設備，則可能只能透過外部 I/O、感測器、HMI 畫面或影像取得資訊。
設備商、自動化商、IT 與 OT，責任不一致的整合難題
很多設備聯網專案技術上可以完成，後續卻難以維護。
在方案導入前，責任邊界會是一件需要被定義清楚的必要前提。
設備商熟悉機台與製程；自動化商負責 PLC、HMI 與控制邏輯；終端用戶的IT 管理企業網路、帳號與伺服器；OT 或設備部門則負責產線可用性與設備維護。
當新系統需要讀取 PLC 時，會立即出現幾個問題：誰有權利提供 Tag List？誰允許修改 PLC？Gateway 故障由誰維修？設備資料錯誤由設備商、SI 還是 IT 判斷？遠端登入後若修改參數，又由誰承擔生產責任？
成熟的維護流程需要把客服、服務工程師、研發、製程、品質、零件物流、IT／OT、資安與業務責任分開。遠端功能一旦涉及控制器、帳號、網路與設備資料，就不可能只由單一資訊部門負責。因此，設備數位轉型前先定義 RACI 或等效責任矩陣，再談系統串接。
設備數位化可以分成三個層次
部份工廠目前最大的問題，是 OT 人員需要走到設備前才知道發生了什麼事。
這類場景可以先處理「看得到」。例如集中觀看 HMI、警報畫面與設備狀態，讓控制室或值班工程師先在遠端就可以完成初判。
對封閉設備、舊版 OS、禁止安裝 Agent 的設備，畫面可視化通常比直接修改控制系統更容易控制風險。這種方式視為 Legacy OT 的實務切入點，尤其適用於多品牌、新舊世代機台混用與不允許修改設備 OS 的場域。
當企業需要 OEE(設備綜合效率)、停機分析、品質追溯或維修趨勢時，就要進入設備數據層。
此時可透過 PLC 資料擷取、OPC UA、SECS/GEM、Gateway 或 Edge 裝置取得結構化資料。
這一階段可能被輕易忽略的是資料語意。Alarm Code、Equipment ID、Recipe、Lot、時間戳、工程單位與設備狀態如果沒有共同定義，資料即使進入 Historian 或 Data Lake，也難以使用及進一步分析。
正確的順序整理為 Asset → Connectivity → Data Quality → Context → Application，也就是先確認設備，再確保穩定連線，接著處理資料品質，最後才進入應用及分析。
AI 適合處理異常辨識、預測維護、畫面告警判讀或製程分析。
前提是資料穩定可用。
如設備名稱、Tag、Scaling、Lot ID、Recipe ID、Alarm Code 與 Timestamp 若缺乏一致規則，即使收集大量設備數據，不代表可直接抛給 AI。
設備畫面可視化、設備聯網與 AI 判斷具有明確的成熟度順序。企業不需要等所有設備都完成全面聯網才開始改善，但也不宜在資料基礎尚未建立時，先投入複雜模型。再者，機敏型資料是否上雲，也是企業需考量地端AI 導入可行性。
全面換機、原機改造、Edge Gateway，哪一種適合？
導入方式比較表：
| 導入方式 | 適用情境 | 相對成本 | 停機風險 | 擴充性 | 維護難度 |
|---|---|---|---|---|---|
| 全面換機 | 製程能力不足、設備故障頻繁、關鍵零件停產、無法支援未來製程 | 高 | 高 | 高 | 中 |
| 控制器 / IPC 原機改造 | 設備仍有價值，但 PLC、HMI、IPC 已老化 | 中至高 | 中至高 | 中至高 | 中至高 |
| PLC / 通訊資料擷取 | 控制器可用，介面可讀取 | 中 | 低至中 | 高 | 中 |
| 外掛式 Edge Gateway | 多品牌、多世代設備，希望降低控制核心的變更 | 低至中 | 低 | 高 | 中 |
| 畫面或外部訊號擷取 | 封閉設備、舊 OS、無 API、禁止修改原機 | 低至中 | 低 | 中 | 中 |
優先納管那些設備？
第一批設備不一定是最容易連線的設備。
從營運的影響程度以判斷優先順序。
高稼動率與瓶頸設備適合優先處理，因為非計畫停機直接影響產能。高維修成本、備品取得困難或經常需要跨區支援的設備，也有比較高的管理價值。
第二個是品質關鍵設備的納管。異常如果會造成大量重工、報廢或批次品質風險，設備數據的價值會高於一般輔助設備。
另一類是「異常難追蹤」的設備。現場若仍靠人工抄表、電話詢問、HMI 截圖或老師傅經驗判斷，代表資料缺口已直接影響維修與管理。
可將評估條件集中在五項：設備對產能的影響、單次故障處理成本、品質關聯程度、異常追蹤難度，以及目前的設備數據缺口。
如何處理舊版 OS、封閉控制器、無法直接連網？
處理原則可以濃縮成：區隔資料採集路徑與即時控制路徑。
前段提到舊機第一階段先以 Read-only 外掛取得資料。為了取得 OEE 或設備狀態，不宜直接修改已穩定運行的 Interlock 或 Motion Control。只有在確實需要下 Recipe、Start／Stop 或 Parameter 時，才建立經過驗證與權限控制的雙向通訊。
舊 OS 無法 Patch 時，也不宜為了符合 IT 更新政策而強制升級。可先採 Network Isolation、Allowlisting、Jump Host、Gateway 等補償性控制，再依設備生命週期安排改造 ( Retrofit )。
OT 資安的判斷重點是生產可用性與風險控制，先別讓所有設備直接連上企業網路。
從單一製程、小範圍開始執行PoC
設備數位化最容易失控的方式是一開始就進行全廠串接。
更實際的方法，是選擇一個製程、一個控制室或一組關鍵設備，先建立比較、評估或起點的標準狀態。
建議 PoC 可控制在一個站點、兩至三種固定異常及二十至四十個端點，並用數週時間進行驗證。PoC 必須驗證資料完整性、診斷效率、資安、維護流程與組織接受度。
KPI 可依企業實際問題設定，例如異常發現時間、首次回應時間、遠端初步判斷準確率、現場出勤次數、非計畫停機時間、設備資料完整度、人工抄錄時間等等。
建立前後比較的準則。
升級既有設備常見的五種錯誤
第一種是如前段所敍述，來源資料不穩的情況下就導入 AI，再處理設備資料。資料來源不穩定，模型很難形成可靠的判斷標準。
第二種是只確認連線成功，沒有確認資料品質。Timestamp 錯誤、Tag Mapping 不一致或資料品質旗標異常，都可能讓上層分析失效。
第三種是忽略設備權限與維護責任。專案完成後若沒有明確 Owner，PLC、Gateway、網路與平台的問題很容易陷入責任模糊的灰色帶。
第四種是一次串接過多設備。不同世代、不同品牌與不同協定會迅速放大工程複雜度。
第五種是只比較硬體價格。真正的總持有成本還包含 Driver、通訊開發、資安審查、文件、備份、現場工程、維修與後續維護及擴充。
即使新設備使用 OPC UA，也不代表整合工作會直接消失。實務案例包括大量 Tag 重連、Timeout、錯誤時間戳與憑證問題。新設備降低的是介面缺乏問題，但同時增加了憑證、Firmware、Patch 與資料版本管理工作。
如何挑選升級既有設備的供應商？
第一個評估點是跨品牌與跨世代整合能力。
供應商不能只展示新型 PLC 或單一品牌 Demo。應確認是否能處理 OPC UA、Modbus、SECS/GEM、Serial、Vendor Protocol，以及沒有標準資料介面的 Legacy 設備。
第二個評估點是 OT 資安。供應商應能說明網路分區、最小權限、唯讀模式、遠端核准、帳號生命週期與稽核方式，而不是單純要求工廠開 Port 或建立永久管理員帳號。
現場工程能力也很重要。既有設備專案常遇到缺文件、舊通訊卡、授權問題、特殊 HMI、Tag Mapping 與設備原廠限制。只具備軟體開發能力的團隊，很難獨立處理完整案場。
文件與維護機制則決定三年後能不能繼續使用。企業應要求交付設備清冊、通訊矩陣、網路架構、Tag Dictionary、帳號權限、備份還原程序、版本紀錄與故障處理窗口。
最後要確認長期技術支援與責任邊界。當遇到以下問題：設備讀不到資料？PLC 被修改後由誰承擔？Gateway 故障的服務協議 (SLA)，新增其他品牌設備是否需要重新開發？供應商退場後，設定與文件是否可由企業接手？
以上問題通常比第一期硬體採購金額更影響長期的隱形成本。
既有設備漸進式升級的判斷框架
企業可以用一套簡單順序做決策。
先判斷設備本體是否仍符合製程、品質與產能需求。若設備本身已成瓶頸，再優先評估汰換。
設備仍有生產價值時，再盤點 PLC、HMI、IPC、OS、韌體、備品與原廠支援狀況。控制系統老化但機械狀態良好，可評估改造 ( Retrofit )。
接著確認資料取得方式。能安全讀取 PLC 或標準介面的設備，可以優先做 PLC 資料擷取。無法直接連網的舊設備，可評估 Edge Gateway、Serial Gateway、外部訊號或畫面的可視化。
之後處理資料品質、設備識別、時間同步與責任分工。這些基礎完成後，再擴大設備聯網範圍，最後才導入預測維護、異常辨識或 AI 應用。
以台灣製造業來說，設備聯網、品質數據化、能源管理是中小型企業較低後悔的投資方向。
對廠長、製造主管與設備主管而言，第一個採購除了面臨的題目是「要買哪一套智慧製造平台」，還得要為現有設備清單、哪些設備仍值得使用、能取得什麼資料，以及要付出多少停機與變更風險。先建立設備清冊、通訊能力、資料取得方式、PLC／HMI 生命週期、OT 資安限制與維護責任。這份盤點完成後，企業始有足夠訊息進而決定設備保留、改造、外掛聯網，以及哪些設備應直接汰換。
延伸閱讀
