AI 驅動文件
您想了解什麼？
MES 與 PLC 整合模式
本頁是控制工程師參考手冊，描述相機在實際工廠中的整合方式。它與 Integration Builder（用於生成 Node-RED 流）以及 IO Helper（用於生成接線+ API 呼叫序列）配套。
標準架構
在 90% 的安裝場景中，路徑為 MES → PLC → Camera，而不是直接從 MES → Camera。
Per-part decisions (ms) Aggregate decisions (sec)
------------------------ --------------------------
Barcode scan ----+
Operator HMI ----+--> PLC --recipe ID--> Camera
MES work order --+ ^ |
| <--pass/fail-- |
| <--defect class--+
Reads result,
fires reject gate
in 10-50ms PLC packages event
{WO, lot, serial, recipe,
+----------------------------> result, defect, timestamp}
|
v
MES
(OEE, quality, traceability,
hold-the-order decisions)
|
v
ERP
關鍵要點：
- PLC 做出每件的拒絕判定。它必須在毫秒級做出響應。MES 做不到這一點（太慢、不可確定）。
- 相機 將透過/失敗的結果報告給 PLC，而不是直接報告給 MES。
- Recipe selection 透過 PLC 流轉。MES 可能決定 which recipe 應該執行，但 PLC 將 recipe ID 寫入相機（透過 EtherNet/IP
O.Data[4-5]或等效的 PROFINET 字）。 - MES 從 PLC 接收上下文化事件（work order、lot、serial、station、recipe、pass/fail、defect class），並做出聚合決策（當 scrap rate 超過閾值時暫停工單、通知質量工程師、更新 OEE）。
- PLC shift register 將檢驗結果與下游拒絕門位置同步，時間以編碼器脈衝為索引。
三種模式
A. PLC 向 MES 彙報（標準模式）
預設模式。PLC 處理實時拒絕。PLC 將帶有工單上下文的結果打包並透過 OPC UA 或 MQTT 轉發至 MES。
適用場景： 任何帶 PLC 的生產線。在汽車、包裝、食品/飲料、製藥等行業常見。
端點序列（在除錯/投產時僅設定一次）：
| 步驟 | 方法 | 路徑 | 目的 |
|---|---|---|---|
| 1 | GET | /edge/download/industrial_ethernet/ethernet_ip_eds | 下載 EDS 檔案（韌體匹配）。交給 PLC 程式設計師。 |
| 2 | POST | /edge/recipe/change_plc_recipe_id | 將 camera 的 recipe 對映到 PLC 友好 ID（1、2、3…），以匹配 MES SKU 程式碼。 |
| 3 | POST | /edge/environmental_variables | 將 plant context（產線程式碼、MES URL）持久化，用於 Node-RED flow。 |
| 4 | GET | /edge/nodered/flow | 讀取活動的 Node-RED flow。 |
| 5 | POST | /edge/nodered/flow | 部署更新後的 flow，搭載 OPC UA / MQTT 釋出器。 |
B. 相機與 PLC 並行釋出（現代並行架構）
PLC 仍然處理不合格件的判定。相機也直接向 MQTT 或 OPC UA 釋出更豐富的有效載荷（image_ref、defect class、confidence），用於歷史資料庫、儀表板和 AI 訓練。與 PLC 路徑並行執行，而非取代它。
使用場景： 實施 Unified Namespace 的工廠（HiveMQ + Ignition + Grafana、Litmus Edge、HighByte）。新建的工業4.0 站點。
端點序列：
| Step | Method | Path | Purpose |
|---|---|---|---|
| 1 | GET | /edge/nodered/flow | 讀取當前活動流程。 |
| 2 | POST | /edge/nodered/flow | 部署一個 flow，使用 mqtt-out（或 sparkplug-out），指向你的代理伺服器。 |
| 3 | GET | /edge/capture_result | 可選：在初始同步期間回填歷史結果。 |
| 4 | GET | /edge/capture_result/{capture_id}/heatmap | OV80i：獲取失敗檢查的缺陷熱圖 PNG。 |
相機內建 MQTT 代理伺服器，地址為 ws://{camera_ip}:9001/mqtt，因此小型部署無需外部代理伺服器。
C. 獨立模式（無 PLC）
沒有生產 PLC。操作員應用程式或雲 MES 透過 REST 直接與相機通訊：拉取工單、切換配方、觸發檢查、獲取結果。操作員即執行器。
使用場景： 返工工位、實驗室檢查、來料檢驗、帶平板的 Tulip 風格雲 MES，以及退貨/反向物流。
不推薦用於： 高速傳送線（無法實現實時拒絕）、需要具備認證 PLC 安全邏輯的受監管環境。
端點序列（每次檢查）：
| Step | Method | Path | Purpose |
|---|---|---|---|
| 1 | POST | /edge/api/recipes/{plc_recipe_id}/activate | 切換到與掃描條碼/工單匹配的配方。 |
| 2 | POST | /edge/camera/capture | 透過 REST 觸發一次檢查。 |
| 3 | GET | /edge/capture_result | 輪詢獲取最新結果（或訂閱 MQTT 以實現推送交付）。 |
| 4 | POST | /edge/v2/capture/{capture_id}/notes | OV80i：將工單上下文附加到捕獲以實現可追溯性。 |
| 5 | POST | /edge/camera/do | 可選：由 MES 應用觸發一個堆疊燈段。 |
規範的檢查結果結構
無論模式或傳輸方式如何，這都是通用有效載荷。請將其作為相機與 MES 之間的契約。
| 欄位 | 型別 | 必填 | 示例 |
|---|---|---|---|
timestamp | ISO 8601 | 是 | 2026-04-13T14:23:51.234Z |
part_id | string | 是 | SN-A7841 |
lot_id | string | 否 | L-2026-04-13-A |
work_order | string | 否 | WO-78451 |
station_id | string | 是 | STA-INSP-3 |
recipe_name | string | 是 | Bottle 330ml v3 |
result | enum (PASS / FAIL / INCONCLUSIVE) | 是 | PASS |
defect_class | string[] | 否 | ["scratch", "dent"] |
confidence | float (0.0 to 1.0) | 否 | 0.987 |
image_ref | URI | 否 | s3://acme-vision/2026/04/13/cap-12345.jpg |
operator_id | string | 否 | op.jane.doe |
cycle_time_ms | integer | 否 | 187 |
常見誤解
"MES 告訴相機應該使用哪一個配方。" 在標準 PLC 架構中，這是錯誤的。MES 告訴 PLC。PLC 告訴相機。唯一的例外是 Pattern C（沒有 PLC）。
"MES 做出拒絕決定。" 錯誤。是 PLC 做的。MES 只做聚合決策，例如“如果廢品率超過 2% 則暫停工單。”
"相機直接向 MES 彙報。" 在標準架構中這是錯誤的。相機彙報給 PLC。PLC 將資料打包並帶上上下文後轉發給 MES。唯一的例外是 Pattern B 的並行路徑，其中相機 也向 MQTT/UNS 釋出更豐富的有效載荷用於分析，但這條路徑與 PLC 路徑並行執行。
下一步
- 使用 IO Helper 將相機 + PLC + 感測器連線並生成 EDS 檔案、位對映，以及 MES 整合腳手架。
- 使用 Integration Builder 基於自然語言描述生成實際的 Node-RED 流（MQTT 釋出器、OPC UA 寫入器、向 MES 傳送 REST POST 請求 等）。