第三章:技術基石-塑膠射出廠後端建置與技術架構
在第二章闡明了智慧製造的核心概念後,本章將深入技術的「核心地帶」,詳細拆解實現這一切的後端資訊架構。這套架構是確保數據從生產現場(OT)穩定、安全地流向決策應用(IT)的神經系統。
我們將依循「OT→Edge→PMC Server→API→Apps」的五層式設計,由下而上地解析:如何透過 OPC UA Gateway 整合異質機台、PMC Server 如何成為工廠的數據中樞,以及如何利用 RESTful API 將數據安全地「服務化」,為上層應用提供穩固的技術基石。
本章節快速導覽:
- 3.1 塑膠射出產業的後端資訊架構
- 3.2 塑膠射出機台聯網OPC Gateway
- 3.3 塑膠射出資料中樞-集中式 OPC UA PMC Server
- 3.4 塑膠射出RESTful API控管
- 3.5 塑膠射出後端資訊架構總結
Author:Jush Li
3.1 塑膠射出產業的後端資訊架構
在整個智慧製造解決方案中,一張清晰的OT→Edge→Database→API→ Apps架構圖是溝通與規劃的第一步。以下我們將由下而上,逐層剖析其核心元件與資料流,並說明各層的功能與價值。
圖 3.1-1:塑膠射出後端建置與技術架構
3.1.1 OT層(Operational Technology Layer)
塑膠射出生產現場的多元數據,如下:
- 各式射出機台:包含日精(Nissei)、舜展(Shuenn Jaan)、宜得世(EdeX)、義展(YC)等機台。
- 協定多樣化:機台彼此之間使用Modbus RTU/TCP、EtherNet/IP、PROFINET、專有文字檔或私有通訊協定,形成「資訊孤島」。
- 塑膠射出產業挑戰:如何在不改動原廠韌體的前提下,將這些塑膠射出差異數據統到一個統一格式?
3.1.2 邊緣運算層(Edge Layer)
研華工業電腦+PMC Server+本地資料庫
- 核心硬體
- 採用Advantech工業級IPC作為邊緣平台,具備高可靠性、防塵防潮及長期 24/7 運行能力。
- PMC Server(OPC UA Server)
- 透過OPC UA標準協定,將底層各種Modbus、私有檔案、EtherNet/IP 等資料「翻譯」為統一的資訊模型。
- 典型儀表板顯示伺服器端點 opc.tcp://localhost:62546/OPCUAServer、連線數、訂閱數及管理中的標籤數(Item Count)。
- 本地儲存
- 一支OPC UA Client程式持續訂閱 PMC Server 的所有數據,並將即時數據寫入本地關係式/時序資料庫。
- 資料庫中可見每筆DeviceID、稼動時段、Utilization等產線關鍵指標。
- 核心硬體
3.1.3 資訊應用層(IT/Application Layer)
RESTful API+Swagger UI+終端應用
- 統一數據出口: RESTful API
- 「服務櫃檯」概念:前端應用(戰情室看板、MES、SCADA、行動 App)皆透過 HTTPS 向 API 發出 GET/POST/PUT/DELETE 請求,取得或更新所需資料。
- JSON 格式回應,並以 JSON Schema 嚴格驗證輸入輸出,確保資料完整性。
- 互動式文件:Swagger UI
- 自動載入OpenAPI規範,提供完整端點說明、參數範例與即時測試介面,加速前後端協作。
- 終端應用(Data Consumers)
- 戰情室儀表板:即時顯示 OEE、Cycle Time、稼動率等,支援動態警示。
- MES/ERP系統:結合訂單、物料與成本,實現精準排程與品質追溯。
- 行動管理:管理者手機可隨時監控產線異常、維護進度與生產績效。
- 統一數據出口: RESTful API
3.1.4 小節
這樣的分層架構,不僅全面覆蓋了從「OT 資產」到「IT 應用」的數據流,更為未來功能升級、橫向擴充和跨系統協同奠定了高度可維護、可落地的技術基盤。
3.2 塑膠射出機台聯網OPC Gateway
在從傳統塑膠射出機台邁向智慧工廠的過程中,OPC UA(Open Platform Communications Unified Architecture)提供了一個統一射出機台的通訊標準。它不僅是單純的資料協定,更是一套具備平台獨立性、內建安全機制、豐富資訊模型與雙模式通訊(Client-Server與Publish-Subscribe)的完整架構。透過 OPC UA,工廠能將日精Nissei、宜得世EdeX、義展YC、全力發CLF 及舜展Shuenn Jaan等多模態塑膠射出成型機台的各式感測與控制資料,轉譯為語義化、標準化的資料流,並無縫對接上層的MES、SCADA或雲端分析平台。
3.2.1 OPC UA架構與功能
- 平台獨立性 (Platform Independence):
支援嵌入式微控制器、工業邊緣電腦、Linux伺服器及公有雲部署,消弭作業系統與硬體差異。此設計使 OPC UA 成為工業4.0理想的通訊骨幹,能在異質化環境中實現跨品牌、跨世代的機台連接。
- 內建安全性 (Robust, Built-in Security):
- 會話加密 (Session Encryption):TLS/SSL保護資料傳輸
- 訊息簽章 (Message Signing):驗證來源與完整性
- 509 雙向驗證:確保僅授權客戶端/伺服器可連線
- 細粒度存取控制:依身份精確授權讀寫權限
- 稽核追蹤 (Auditing):記錄所有重要操作活動
這套多層次安全模型,對於將OT系統安全地連接到IT網路與雲端至關重要。
- 資訊模型 (Information Modeling):
採物件導向設計,將“塑膠射出機”定義為包含屬性(溫度、壓力、產量)、方法(啟動、停止)、事件(異常警示)等完整元件,並結合 EUROMAP 77/82 等夥伴規範,實現「即插即用」語義互操作。訊息不再只是“Tag: Temp_1 = 150.2”,而是帶有上下文與行為的結構化資訊,為後續 AI 與深度分析鋪路。
- 雙模式通訊 (Client-Server 與 Publish-Subscribe):
- Client-Server:可靠的一對一請求-回應,適用於配方下達、區域診斷等場景。
- Publish-Subscribe:透過MQTT/Sparkplug B等訊息代理,適合大規模遙測與雲端數據蒐集。
3.2.2 IIoT Gateway與Edge Device
- 工業物聯網閘道器(IIoT Gateway):置於OT與IT之間,支援RS-485、EtherNet/IP、Modbus等多協定介面,並執行 OPC UA 伺服器。它負責協定轉換、資料封裝與安全隔離,確保傳統 PLC、感測器與專有機台能透過統一端點接入企業網路。
- 邊緣運算裝置 (Edge Device):具備更強運算與儲存能力,除協定轉換外,還能近源進行資料過濾、關鍵指標計算(OEE、能耗)、本地 AI 推論(如即時品質檢測、預測性維護),大幅降低雲端頻寬負載,並縮減時延。
表 3.2-1:工業物聯網閘道器與邊緣電腦比較
特性 | 工業物聯網閘道器 (Industrial IoT Gateway) | 邊緣電腦 (Edge Computer) |
主要功能 | 協定轉換與數據轉發 | 本地數據處理、分析與控制 |
處理能力 | 低功耗 CPU (例如 ARM, Intel Atom) 22 | 高性能 CPU/GPU/AI 加速器 (例如 Intel Core/Xeon, NVIDIA Jetson) 26 |
關鍵應用場景 | 連接傳統 PLC 至雲端;基本的遠端監控 | 即時品質控制;預測性維護 AI 模型;降低雲端頻寬成本 17 |
數據流 | 轉發大部分原始或輕度過濾的數據至中央系統 28 | 在本地處理數據,僅傳輸高價值資訊或警報 |
決策延遲 | 高 (取決於網路與雲端的往返時間) | 極低 (可實現即時的機台級決策) 24 |
相對成本 | 初始投資較低 36 | 初始投資較高 |
產品範例 (台灣) | Advantech EKI-1200 系列, ICP DAS tGW-700 系列 37 | Advantech ECU-1000 系列, Premio RCO-1000 系列 22 |
3.2.3 多品牌塑膠射出機聯網模式
1. 日精 NEX-V 系列(原生 OPC UA)
- 做法:射出機台乙太網路直連閘道器或交換器,OPC UA Client透過IP 即時抓取近200支API(螺桿位置、保壓壓力、射出速度等),結合EUROMAP 77/82完成語義化資料傳輸。
- 優勢:即插即用、標準化程度高、毫秒級更新。
2. 全力發 CLF-200 系列(PLC + Modbus)
- 做法:IIoT Gateway作為Modbus Master週期計數器CycleCounter、MoldOpenTime、PowerConsumption等寄存器,將擷取資料封裝為OPC UA Server端點,再推送至邊緣Sparkplug B Broker,供能耗與效能分析。
- 優勢:秒級更新、靈活支援既有PLC。
3. 宜得世 EdeX(V-Connect 專有檔案)
- 做法:閘道器或伺服器端應用程式監控.csv/.txt製程波形檔,將塑膠射出速度、V-P切換點、冷卻時間等關鍵變數自動解析並映射為OPC DataSet,彙入資料湖。透過PCA降維與Cycle Signature指紋模型,一旦高維數據偏離正常,即發出異常預警並納入維護優先池,實現「生產異常前檢」。
- 優勢:無須破解專有通訊,利用穩定檔案格式整合批次數據。
4. 義展 YC/舜展 Shuenn Jaan(機械手與 CNC)
- 做法:若控制器原生支援OPC UA,採直連;否則透過IIoT Gateway接 EtherNet/IP、PROFINET、Modbus TCP,再以OPC UA對外發佈。
- 優勢:跨製程 Trace-ID,客戶端掃描產品QR Code可回溯射出-去澆口-精修的完整參數,符合IATF-16949 APQP 4.0製程履歷追蹤需求。
3.2.4 機台連接矩陣
機台品牌 | 型號/年代 | 可能的原生協定 | 建議連接硬體 | 策略與關鍵實施說明 |
日精 (Nissei) | 現代, NEX-V | 原生 OPC UA | 無需 | 直接將機台乙太網路埠連接至工廠網路。 |
日精 (Nissei) | 傳統 | 文字檔匯出 | IIoT 閘道器 / 伺服器腳本 | 監控網路共享區的 MONDAT 檔案,解析並轉換為 OPC UA。 |
宜得世 (EdeX) | V Connect 系統 | 專有檔案系統 | IIoT 閘道器 / 伺服器腳本 | 監控 V Connect 檔案伺服器,解析專有檔案並轉換。(註:直接介接協定風險高)。 |
全力發 (CLF) | PLC 控制 | 很可能是 Modbus | 工業協定閘道器 (Advantech/ICP DAS) | 連接至 PLC 埠,輪詢 Modbus 暫存器,並以 OPC UA 格式發布。(註:需有 PLC 暫存器對照表)。 |
義展/舜展 | 控制器為基礎 | 多樣化 | 工業協定閘道器 | 識別控制器協定 (如 EtherNet/IP, Modbus TCP),使用相應的閘道器進行轉換。 |
3.2.4 小結
結合OPC UA的三大支柱-平台獨立性、內建安全性與豐富資訊模型,加上 IIoT Gateway與Edge Device的協同,無論射出機台新舊、協定差異或封閉程度,皆可建立一條安全、可擴展、語義化的塑膠射出機台資料管道,來實現「即時智慧製造」。
3.3 塑膠射出資料中樞-集中式 OPC UA PMC Server
在整體架構中,位於OT與IT之間的PMC Server軟體(部署於研華工業電腦上)扮演了整廠數據中樞與OPC UA Server的雙重角色。所有塑膠射出機台(如日精 Nissei、舜展 Shuenn Jaan)與邊緣閘道器所採集的數據,皆匯聚至此,並以統一的OPC UA介面公開,供各類 OPC UA Client(MES、SCADA、資料庫)連接與讀取。
3.3.1 PMC Server 作為資料中樞與 OPC UA Server
- 部署平台:研華工業電腦(Advantech IPC)
- 功能定位
- 數據整合:PMC Server 透過 Modbus、EtherNet/IP、或專有協定,連線並擷取各品牌機台的原始感測與控制點。
- 標準化發布:將擷取到的多廠牌數據依照 OPC UA 規範,組織為「地址空間」(Address Space)中階層化的物件與 Tag。
- 安全連線:支援 TLS/SSL 加密與 X.509 驗證,確保上層系統連線安全。
- 關鍵指標
- Endpoint:opc.tcp://
:52545/OPCUAServer - 活躍連線:可容納數十個 Client 同時訂閱與讀取
- 管理 Tags:典型部署下管理千餘個機台 Tag(如狀態、參數、計數器等)
- Endpoint:opc.tcp://
3.3.2 架構說明:從OT→PMC→IT的數據流
- OT層(數據源)
- 日精、舜展、全力發、宜得世等射出機台
- 邊緣閘道器/IIoT Gateway負責協定轉換與本地採集
- 中介層(PMC Server)
- 擔任 OPC UA Server,將所有機台資料整合於一個「地址空間」
- 如下圖所示,PMC Server 的儀表板清晰顯示伺服器狀態、連線數、Subscriptions 及管理的 Data Items(Tags)
- IT層(存儲與應用)
- 驗證工具:UaExpert 等 OPC UA Client 可瀏覽完整地址空間,檢視每個機台下的 Heater、Injection、CycleCount 等結構化物件
- 本地歷史庫:PMC Server 同時將資料寫入本地資料庫(如 MySQL/SQL Server),做為 Historian 用以歷史趨勢分析
- 上層系統:MES、SCADA、雲端分析平台透過 OPC UA 介面或直接查詢資料庫,實現即時監控與長期優化
- OT層(數據源)
圖3.3-1: OPC UA 伺服器 (PMC Server)
3.3.3 客戶端視角與儲存流程
- 地址空間瀏覽
- 在UaExpert中,「R-NesseiNEX360…」與「M-ShuennJaan300ED…」分別對應不同品牌機台,展現了多品牌無縫整合
- 每台機台以物件化方式呈現:Heater、HoldPressure、Injection、MoldClose 等分類,帶來語義化檢索
- 地址空間瀏覽
圖3.3-2:OPC UA 客戶端 (UaExpert)
- 數據儲存
- PMC Server內建本地 Historian,將資料持久化至隨機存取資料庫
- 運用Navicat(或其他管理工具)監控資料表狀態,並供往後報表系統查詢
- 數據儲存
圖3.3-3:Navicat客戶端 (資料庫查詢)
3.3.4 小結
透過PMC Server的集中式OPC UA Server架構,可將分散於各生產線與閘道器的異質數據,統一整合、結構化並安全發布。所有上層應用程式與歷史庫,皆能以同一標準介面存取即時與歷史數據,打造完備的數據應用。
3.4 塑膠射出RESTful API控管
在完成OT層資料採集(3.2節)與PMC Server的集中管理(3.3 節)後,3.4 節將聚焦於如何將底層庫存的機台數據轉化為真正可被前端應用與資訊系統消費的「服務」。透過 RESTful API、JSON Schema 與 Swagger UI,我們能夠在保證安全、可控與可維護的前提下,構建一個標準化的 API,讓所有智慧製造應用都能輕鬆、穩健地取用資料。
3.4.1 為何要需要標準化API?
當所有機台數據透過PMC Server彙整並寫入本地資料庫後,如果前端應用(如生產看板、MES、SCADA)或報表系統直接連接資料庫,將面臨以下風險與挑戰:
- 安全性風險
- 資料庫憑證與結構暴露,容易成為駭客攻擊的目標。
- 高耦合度
- 資料庫結構任何微小變動,都可能讓多個客戶端程式一一停擺。
- 缺乏存取控管
- 難以針對不同使用者或應用,實施欄位級別的讀寫權限管理。
- 安全性風險
為了解決上述問題,我們採用RESTful API作為對外的「服務櫃檯」。所有外部應用要取用機台資料,必須透過這套統一的HTTP介面,不會直接操作底層資料庫,從而大幅提升整體的安全性、彈性與可維護性。
3.4.2 RESTful API:資源導向的服務窗口
REST(Representational State Transfer)架構風格已成業界標準。我們將資料庫中的每一項資源(如機台清單/devices、產能利用率/utilizations)都對應一組 URL,並用 HTTP 動詞來定義對資源的操作:
- GET /devices:取得所有機台列表
- GET /devices/{id}:取得單一機台詳情
- POST /devices:新增一台機台
- PUT /devices/{id}:更新既有機台資訊
- DELETE /devices/{id}:刪除指定機台
每一次請求都必須攜帶有效的Bearer Token或API金鑰,以滿足授權與審計需求;伺服器本身不保存客戶端的任何會話狀態(Stateless),確保了橫向擴展時的簡潔性。
3.4.3 JSON Schema:嚴格控管的資料格式
在 RESTful API 中,我們採用JSON(JavaScript Object Notation)作為資料交換格式。JSON 具有輕量、可讀、跨語言支援等優勢,非常適合前後端分離的架構。然而,僅靠 JSON 本身並不足以保證資料品質。為此,我們引入 JSON Schema:
- 定義欄位類型:字串、整數、布林、日期…
- 設置必填欄位:如 id、tagName、value、id、device.name
- 格式驗證:透過正則表達式強制數值格式,例如壓力值只能是「整數或兩位小數」。
- 層次結構檢查:嵌套物件與陣列都能被精確驗證,避免前端收到結構不符的意外資料。
如此一來,當前端呼叫GET/tags/{tagId},伺服器回傳的JSON一定符合預先定義的Schema;同樣,當應用程式發起 POST/alerts建立異常通知時,也會先通過Schema 驗證,杜絕錯誤或惡意資料進入資料庫。
表3.4-1 JSON API資訊
JSON統一格式 |
{ "id": "A-ShuennJaan160Ei.HoldPressure.Point(1).rPressure", "tagName": "HoldPressure.Point(1).rPressure", "group": "SetValue", "name": "射出入料-保壓一段壓力", "value": "50.00", "device": { "id": 1, "name": "A-ShuennJaan160Ei" } } |
3.4.4 Swagger UI:互動式的 API 文件與測試平臺
要讓前端工程師或資訊人員迅速上手,Swagger UI扮演了不可或缺的角色。
- 自動生成文件
- 我們將所有API 端點、請求參數、Response 格式,描述於一份 OpenAPI YAML 檔案中。
- Swagger UI讀取這份規範後,自動呈現成美觀、分門別類的互動式介面。
- 即時測試
- 使用者可以直接在瀏覽器上,對任意端點進行參數輸入與呼叫,並立即查看回傳結果。
- 無需手寫任何測試程式碼,就能完成初步的介面驗證與除錯。
- 前後端協作契約
- 這份文件成為開發的「契約」,任何改動都同步反映在 Swagger UI。
- 前端、後端以至於整個團隊,都可在同一份文件上無縫協作,提高專案效率。
- 自動生成文件
圖3.4-1:Swagger UI
3.4.5 小節
透過RESTful API、JSON Schema 與Swagger UI,您不僅將工廠機台數據集中管理,還將其進一步「服務化」、「標準化」,真正實現從資產到資料服務的轉變。前端團隊可以放心依賴API提供的SLA保證,IT團隊也能透過Schema 與文件維護,長期以來無憂地演進與擴充。未來,無論是即時看板、智慧預警、或跨系統協同,皆可在此堅實、可控的基礎上自由施展,驅動企業的數位轉型與競爭力提升。
3.5 塑膠射出後端資訊架構總結
在本章中,塑膠射出產業使用「OT→Edge→Database→API→Apps」五層架構為骨幹,完整勾勒出塑膠射出生產線如何從分散的「資訊孤島」演進為高度整合的智慧製造平台。其核心價值可歸納如下:
1. 端到端的數據通路設計
生產現場各品牌塑膠射出機(Nissei、EdeX、YC、CLF、Shuenn Jaan)透過IIoT Gateways與Edge Devices,將Modbus RTU/TCP、EtherNet/IP、專有檔案與光學/感測擷取等多元數據源,統一轉譯為標準化的OPC UA 資訊模型,成功地消彌了通訊協定與硬體平台的差異
2. PMC Server 作為「數據中樞」
部署於研華IPC 上的 PMC Server軟體,擔綱OPC UA Server的角色,將所有機台感測與控制點綜合彙聚,並以結構化、語義化的地址空間(Address Space)發布逾千個 Tag。上層 MES、SCADA、趨勢分析或自建資料庫皆可作為OPC UA Client直接訂閱,即時讀取或歷史查詢,實現完整的OT→IT數據閉環。
3. RESTful API的「服務化」轉型
依據業界最佳實踐,我們在本地資料庫之上構建了安全、無狀態的 RESTful API層,並以JSON Schema嚴格定義每一筆機台數據的格式與驗證規則。結合Swagger UI互動式文件,不僅提升了前端開發人員的使用效率,也確保了資料存取的安全性、可維護性與高可用性。
4. 全方位安全與可擴展性
- 平台獨立性:OPC UA 可在嵌入式微控制器至公有雲任意節點運行,保障各種廠商與年代機台的無縫接入。
- 內建安全機制:採用 TLS/SSL 加密、X.509雙向驗證與細粒度存取控制,全面防範OT-IT 邊界的資安威脅。
- 橫向擴充:REST API完全無狀態設計,支持多節點水平擴展;Edge Device 可靈活部署於不同產線或工廠。
- 5. 驅動未來深度應用
建立於上述堅實基礎之上,任何AI推論、預測性維護、產品履歷追蹤或跨廠區協同系統,都可無縫切入既有數據管道,享有毫秒級資料更新、語義化上下文資訊與統一安全訪問接口。這使企業具備真正的「數據資產→數據服務→數據價值」轉化能力,全面提升製程能效、品質穩定度與營運決策的敏捷度。
綜觀而言,本章所提出的後端資訊架構,不僅解決了射出產線多品牌、多協定的異質化挑戰,更透過OPC UA、PMC Server與API中台的協同運作,構築了一條「安全、標準、可擴展」的智慧製造高速公路,為塑膠射出業者的數位轉型奠定長期可持續的技術基石。