第二章談到 ERP、MES 與機台聯網各自負責的角色。到了後端架構這一層，問題會變得更實際：不同品牌的機器要怎麼接？資料應該由誰統一管理？前端系統能不能直接讀資料庫？

本章以「OT → Edge → PMC Server / Database → API → Apps」為主軸，說明從射出機到應用系統之間的資料流程。

Author: Jush Li

3.1 射出機聯網的後端資料架構

射出工廠如果只有一個品牌、一個世代的設備，資料整合相對簡單。但實際現場通常同時存在新舊機台，不同控制器能提供的資料、格式與通訊方式也不同。

因此後端不適合讓 MES 直接針對每一台射出機各寫一套程式，而是先把設備端差異集中處理，再提供統一的資料來源。

圖 3.1-1：塑膠射出後端建置與技術架構

3.1.1 OT層（Operational Technology Layer）

OT 層就是實際生產設備。現場可能同時有日精（Nissei）、舜展（Shuenn Jaan）、宜得世（EdeX）、義展（YC）、全力發（CLF）等不同品牌。

問題並不是品牌多，而是每台機器能提供資料的方法不一樣。有的設備支援 OPC UA，有的可能透過 Modbus、EtherNet/IP 或 PLC 讀取，也有部分設備只能從原廠輸出的文字檔、CSV 或共享資料夾取得資訊。

3.1.2 邊緣運算層（Edge Layer）

Edge 層負責把設備差異留在現場端處理。

如果射出機原本就能提供 OPC UA，就可以直接建立 OPC UA Client 連線；如果設備只提供 PLC 暫存器或檔案，就由 Gateway 或邊緣程式負責讀取與轉換。

邊緣端也可以先做資料清理，例如只在數值改變時寫入、標記設備離線狀態，或先計算 Cycle Time 等基本指標，避免所有原始資料都直接丟到上層系統。

3.1.3 資訊應用層（IT / Application Layer）

設備資料整理完成後，上層 MES、看板與其他系統不應再去了解每一台射出機原本使用什麼協定。

它們只需要知道統一的設備編號、Tag、目前值、時間與狀態，再透過 API 或其他標準介面取得資料。

• MES：將設備資料與工單、產品、模具及人員建立關聯。
• 生產看板：顯示目前機台狀態、Cycle Time、模次與停機情況。
• 報表：查詢歷史生產區間、稼動率及異常紀錄。
• 行動系統：讓主管或現場人員透過平板、手機查看必要資訊。

3.1.4 小節

分層最大的好處不是架構看起來完整，而是設備端與應用端不必綁在一起。

未來新增一台機器時，主要處理 OT / Edge；新增一套 App 時，主要使用既有 API。這樣改一邊時，比較不容易牽動整套系統。

3.2 多品牌射出機聯網與 OPC Gateway

OPC UA 常被當成射出機聯網的共同介面，但不是所有設備本身都會提供 OPC UA。

因此實際做法通常分成兩種：原生支援的機台直接連線；其他設備則經過 Gateway 或資料轉換程式，再統一提供給上層使用。

3.2.1 OPC UA架構與功能

OPC UA 的實用之處，在於它不只傳送一個數字，也可以把設備、物件與資料節點整理成有結構的 Address Space。

例如系統看到的不一定只是「Tag 001 = 31.8」，而可以進一步知道這個節點屬於哪台機台、哪一類資料，以及它的資料型態。

• 跨平台： Client 與 Server 可部署在不同作業系統及設備上。
• 安全連線： OPC UA 提供憑證、訊息簽章、加密與使用者驗證等機制，實際安全等級仍要依工廠設定。
• 資訊模型： 可以使用物件、變數、事件與節點關係描述設備資料，而不是只有單一 Tag 清單。
• 訂閱機制： Client 可訂閱需要的節點，由 Server 在資料變化時更新，不必一直重複全量輪詢。

3.2.2 IIoT Gateway與Edge Device

Gateway 與 Edge Computer 常被混用，但工作重點可以稍微區分。

3.2.3 多品牌塑膠射出機聯網模式

多品牌整合時，不應先假設每個品牌一定使用某一種協定。比較穩妥的方式是依「實際控制器與已開放介面」逐台確認。

1. 原生 OPC UA 機台

如果機台本身已提供 OPC UA Server，可以直接由 OPC UA Client 連線，再讀取原廠開放的節點。

這類設備整合比較單純，但可讀節點數量、更新速度與是否支援 EUROMAP / OPC 40077，仍要依實際機型與選配確認。

2. PLC / Modbus 類型設備

如果控制器提供 Modbus TCP、Modbus RTU 或其他 PLC 通訊介面，可由 Gateway 讀取指定暫存器，再轉成統一資料格式。

這種方法最重要的是拿到正確的暫存器對照表，否則即使通訊成功，也不知道每一個位址代表什麼。

3. 檔案輸出型設備

部分舊設備或原廠軟體會定期輸出 TXT、CSV 或其他格式檔案。這種情況可以監控指定資料夾，解析新檔內容後再寫入資料庫。

更新速度通常不如直接通訊，但如果檔案格式穩定，而且目的是取得 Cycle Time、模次或設定值，仍然可以使用。

4. 其他控制器

若設備使用 EtherNet/IP、PROFINET 或其他協定，就要依控制器實際支援方式處理。不能只看射出機品牌判斷。

3.2.4 機台連接矩陣

3.2.5 小結

多品牌機台聯網沒有一種接法可以套全部設備。

新機可優先使用 OPC UA；舊機則依 PLC、檔案或原廠介面處理。最後再把不同來源整理成一致的設備編號、Tag 與時間資料。

3.3 集中式 OPC UA PMC Server

當各機台資料都能取得後，下一個問題是：要不要讓 MES 分別去連每一台設備？

集中式 PMC Server 的用途，就是讓上層系統先連到一個統一入口，而不是各自處理底層設備差異。

3.3.1 PMC Server作為資料中樞與 OPC UA Server

PMC Server 部署於工業電腦上，將不同機台的資料整理後，以 OPC UA Address Space 對外提供。

對上層系統來說，重要的不是底下原本是 Modbus、文字檔還是其他協定，而是最後都能從同一介面找到對應設備與節點。

• 集中發布：統一提供 OPC UA Endpoint。
• 設備分類：不同機台有固定 Device ID 與資料結構。
• 訂閱：Client 只訂閱實際需要的節點。
• 連線管理：觀察 Client、Subscription 與資料節點狀況。

3.3.2 架構說明:從OT→PMC→IT的數據流

1. OT： 機台、PLC 或 Gateway 產生設備資料。
2. PMC Server： 將資料整理後放進統一 OPC UA Address Space。
3. OPC UA Client： UaExpert、資料採集程式或其他系統訂閱節點。
4. Database： 將需要長期保存的資料寫入 SQL Server、MySQL 或其他歷史資料庫。
5. Application： MES、報表與其他 App 再使用即時或歷史資料。

圖 3.3-1：PMC Server 統一提供設備資料入口

3.3.3 客戶端視角與儲存流程

UaExpert 很適合用來驗證 OPC UA Server 是否正常，也可以瀏覽各機台底下的節點結構。

例如不同設備可以依機台編號分開，再往下分類 Heater、Injection、Cycle、Mold 等資料。實際名稱仍取決於 Server 建立的 Address Space。

圖 3.3-2：使用 UaExpert 驗證 OPC UA 節點與即時數值

真正要做歷史分析時，通常還是需要資料庫。資料採集程式從 OPC UA 訂閱即時資料，再將時間、Device ID、Tag 與 Value 等欄位寫入資料表。

Navicat 或其他資料庫工具只負責查詢與維護資料庫，本身並不是製造資料採集系統。

圖 3.3-3：資料寫入資料庫後，可再供報表與歷史分析查詢

3.3.4 小結

集中式 OPC UA Server 的目的，是減少上層系統與各設備直接耦合。

即時資料走 OPC UA，歷史資料依需求寫入資料庫，兩者分工後，後續要增加報表、MES 或其他應用會比較容易管理。

3.4 RESTful API 與資料存取控管

設備資料進到資料庫之後，最直接的做法是讓每一套系統都直接連 SQL。

小型內部系統有時可以這樣做，但當使用系統越來越多，資料庫帳號、欄位異動與權限會逐漸變難管理。

因此後端可以再加一層 RESTful API，讓前端只跟 API 溝通。

3.4.1 為什麼需要標準化 API？

• 降低資料庫暴露： 前端不需要直接持有資料庫帳密。
• 降低耦合： 資料表結構調整時，可以由 API 層維持對外格式。
• 權限控管： 不同系統只取得自己需要的資料與操作權限。
• 統一格式： Web、MES、手機 App 可以使用同一套資料來源。

3.4.2 RESTful API：資源導向的服務窗口

API 不需要把資料庫每張表完整開放出去，而是依實際應用設計資源。

例如：

GET /devices取得設備清單GET /devices/{id}取得指定設備資訊GET /devices/{id}/status取得目前機台狀態GET /devices/{id}/cycle-time取得機台 Cycle TimeGET /production-sessions/{id}取得指定生產區間資訊

至於 POST、PUT、DELETE 是否開放，應視業務需求決定。設備即時資料很多情況只需要讀取，不必為了符合 REST 形式而把所有 CRUD 操作全部做出來。

3.4.3 JSON Schema：固定資料格式

JSON 適合前後端交換資料，但 JSON 本身不保證欄位一定正確。

因此可以透過 Schema 或程式模型定義欄位型態、必填欄位與允許範圍。

製造資料尤其要注意數值和字串不要混用。如果 Pressure 本質上是數值，API 最好直接傳數值型態，而不是每次都傳 `"50.00"` 字串。

例如：

{  "id": "A-ShuennJaan160Ei.HoldPressure.Point1.Pressure",  "tagName": "HoldPressure.Point1.Pressure",  "group": "SetValue",  "name": "保壓一段壓力",  "value": 50.00,  "timestamp": "2026-08-25T10:32:15+08:00",  "device": {    "id": 1,    "name": "A-ShuennJaan160Ei"  }}

這裡增加 timestamp 很重要。製造資料如果只有 Value，卻不知道這個值是哪個時間取得的，之後很難用於製程追溯。

3.4.4 Swagger UI：API 文件與測試介面

Swagger UI 的用途是讓開發人員看懂 API。

透過 OpenAPI 規格，可以清楚列出 Endpoint、Request、Response、資料型態及授權方式。前端在串接前，可以先從瀏覽器測試 API 是否符合預期。

• 不用另外維護一份容易過期的 Word API 文件。
• 新增欄位或 Endpoint 時，前後端比較容易同步。
• 可以直接看到範例 Request 與 Response。
• 問題發生時，也比較容易確認是 API 還是前端程式造成。

圖 3.4-1：Swagger UI 用來檢視與測試 API 介面

3.4.5 小節

API 層真正解決的問題，是不要讓每一套前端程式直接綁住底層資料表。

資料庫負責儲存，API 負責對外提供資料規則。未來換前端、增加手機 App 或增加另一套報表時，就能繼續使用同一個資料入口。

3.5 後端架構整理：每一層負責什麼

回到本章最前面的架構，真正需要處理的其實只有一件事：讓資料從設備出來之後，每一層都知道自己負責什麼。

1. OT：先確認設備真的能提供哪些資料

不同射出機的能力不同。新設備可能原生提供 OPC UA，舊設備可能只能透過 PLC 或檔案取得有限資訊。

不要先假設所有機台都能取得相同 Tag，再回頭硬湊資料。

2. Edge / Gateway：把設備差異留在底層

Gateway 負責把不同協定或檔案整理成一致格式。如此 MES 不需要知道底層到底是 Modbus、OPC UA 還是文字檔。

3. PMC Server：提供統一即時資料入口

上層 OPC UA Client 從同一 Server 找設備與節點，避免每一套應用都直接連各品牌機器。

4. Database：留下真正需要追溯的歷史資料

不是所有毫秒級資料都一定要永久保存。應依實際用途決定採樣週期與保存內容，尤其 Cycle Time、模次、機台狀態及重要生產區間最好能和工單建立關聯。

5. API：讓資料可以被其他系統使用

MES、報工、排程、倉儲與行動系統透過固定 API 讀取資料，後端資料庫與前端應用就不會綁得太死。

等工單、機台、模具與時間資料可以穩定對應後，再往異常預警、OEE、能源分析或預測性維護延伸，才比較有實際基礎。

對射出工廠而言，後端架構做得好，平常不一定有人注意；但未來增加新機台、新系統或要追查一批產品時，差異就會很明顯。