泵類型: 離心式冷卻液泵 (Centrifugal Coolant Pump)


泵型號 : CoolFlow Pro 5000


設(shè)備 ID: PUMP-CNC-001


使用場景: 安裝在一臺中型 CNC 立式加工中心 (Machine ID: VMC-03) 上，用于循環(huán)供給水基切削液，冷卻刀具和工件。該機床主要加工鋼材和鋁合金零件，實行兩班倒工作制 (16小時/天)。泵已運行約 18 個月。


關(guān)鍵監(jiān)測參數(shù): 振動 (mm/s RMS), 溫度 (°C), 出口壓力 (Bar), 流量 (L/min)。

1、IoT 數(shù)據(jù) (`IOT.json` & `/api/pump/status`):


    *   包含泵的實時傳感器讀數(shù)，如時間戳 (`timestamp`)、軸向/徑向振動 (`vibration_axial`/`radial`)、電機/軸承溫度 (`temperature_motor`/`bearing`)、出口壓力 (`pressure_outlet`)、流量 (`flow_rate`)。
    *   模擬了數(shù)據(jù)隨時間變化，包含正常和逐漸異常的狀態(tài)。


 2、MES 數(shù)據(jù) (`MES.json` & `/api/mes/pump/operation`):
    *   提供泵的運行日志，關(guān)聯(lián)的設(shè)備 (`associated_machineId`)，運行小時數(shù) (`operating_hours`)，處理的工單 (`jobs_processed`) 等。
    *   有助于了解泵的工作負載和上下文。


3、CMMS 數(shù)據(jù) (`CMMS.json` & `/api/cmms/pump/history`):
    *   包含歷史維護記錄 (`maintenance_records`)：工單號、日期、類型、描述、更換部件、停機時間等。
    *   包含相關(guān)故障信息 (`related_failures_info`)：其他泵（或本機歷史）的故障案例，包括癥狀、故障模式、根本原因、糾正措施。這是重要的知識來源。


4、ERP 數(shù)據(jù) (`ERP.json` & `/api/erp/spare_parts`):
    *   提供備件信息：零件 ID (`partId`)、名稱 (`name`)、描述、適用泵型號、供應(yīng)商、庫存水平 (`stock_level`)、單價 (`unit_price`)、采購提前期 (`lead_time_days`)。
    *   用于生成維護建議時考慮備件可用性。


 模擬維護完成后，實際執(zhí)行情況的反饋數(shù)據(jù)，用于評估預(yù)測準(zhǔn)確性和閉環(huán)優(yōu)化。

ELSE (正常):  流向 ANSWER 節(jié)點，輸出簡單的狀態(tài)正常信息。

IF (異常):  啟動預(yù)測性維護流程。

調(diào)用 GET_CMMS_DATA 和 GET_MES_DATA 獲取歷史維護和運行數(shù)據(jù)。

調(diào)用 KNOWLEDGE_RETRIEVAL 節(jié)點，結(jié)合當(dāng)前異常指標(biāo)查詢知識庫 (離心泵設(shè)備手冊 pdf、歷史維修案例 excel)。

**START:** 定義工作流入口參數(shù) (`pumpId`)。
  **GET\_... (HTTP Request):** 與模擬 API 交互，獲取各類數(shù)據(jù)。
  **CODE (解析 IoT):** 解析 IoT JSON，提取關(guān)鍵指標(biāo)，**計算 `needs_maintenance` 標(biāo)志**。
  **IF/ELSE:** 根據(jù) `needs_maintenance` 標(biāo)志進行流程分支。
  **KNOWLEDGE_RETRIEVAL:** (可選) 連接外部知識庫進行 RAG 查詢。
  **FAULT_PREDICTION (LLM):** 基于多源信息進行故障診斷與預(yù)測。
  **EXTRACT_PART_ID (CODE):** 從 LLM 輸出中解析結(jié)構(gòu)化信息 (Part ID)。
  **PARSE_ERP_DATA (CODE):** 解析 ERP 返回的 JSON 列表字符串。
  **SUGGESTIONS (LLM):** 結(jié)合故障預(yù)測和備件信息生成維護建議。
  **ANSWER / ANSWER 2:** 輸出最終結(jié)果。

1.  HTTP 請求：URL 與參數(shù)混淆
    *   **節(jié)點:** `GET_IOT_DATA`
    *   **報錯:** `Invalid non-printable ASCII character...`
    *   **原因:** 同時在 URL 字段和 PARAMS 字段中定義了查詢參數(shù)。
    *   **解決:** URL 只寫基礎(chǔ)路徑，參數(shù)在 PARAMS 中定義 (推薦: `{{start.pumpId}}`)。


2.  HTTP 請求：網(wǎng)絡(luò)訪問 & CORS 
    *   **節(jié)點:** 所有 HTTP 請求節(jié)點
    *   **報錯:** Dify 404，但 API 日志顯示 200 OK。
    *   **原因:** API 服務(wù)監(jiān)聽地址限制；缺少 CORS 配置。
    *   **解決:**
        *   API (`mock_api.py`): 啟動時 `host='0.0.0.0'`。
        *   API (`mock_api.py`): 安裝 `flask-cors` 并啟用 `CORS(app)`。


3.  數(shù)據(jù)處理：JSON 字符串解析 
    *   **節(jié)點:** `CODE` (解析 IoT), `IF/ELSE`, `ANSWER`
    *   **報錯:** `IF/ELSE` 條件不生效；`ANSWER` 直接輸出占位符。
    *   **原因:** HTTP 節(jié)點返回的 `body` 是 JSON **字符串**，而非結(jié)構(gòu)化對象。
    *   **解決:** 在 HTTP 節(jié)點后加 `CODE` 節(jié)點，用 `json.loads()` 解析 `body` 字符串，輸出解析后的對象/列表供后續(xù)節(jié)點使用。


4.  IF/ELSE 節(jié)點：數(shù)值比較類型問題 
    *   **節(jié)點:** `IF/ELSE`
    *   **報錯:** 數(shù)值比較條件 (`> 6.0`) 不生效。
    *   **原因:** `IF/ELSE` 可能將變量視為字符串進行比較。
    *   **解決:** 將比較邏輯移入 `CODE` 節(jié)點，輸出簡單標(biāo)志位 (如 `"1"`/`"0"` 字符串)，`IF/ELSE` 只判斷此標(biāo)志位。


5.  CODE 節(jié)點：Python 語法 & 類型錯誤 
    *   **節(jié)點:** 所有 `CODE` 節(jié)點
    *   **報錯:** `IndentationError`, `NameError`, `Output variable 'xxx' must be a [Type]`。
    *   **原因:** 縮進錯誤；變量未定義；Dify 輸出類型配置與代碼返回不符。
    *   **解決:** 嚴格檢查 Python 縮進；確保 `return` 前所有變量已定義賦值；確保 Dify 中輸出變量的**名稱和類型**與代碼 `return` **完全匹配** (e.g., Part ID 是 String)。


6.  TEMPLATE 節(jié)點：Jinja2 語法 & 數(shù)據(jù)錯誤 
    *   **節(jié)點:** `TEMPLATE`
    *   **報錯:** `jinja2.exceptions.TemplateSyntaxError`。
    *   **原因:** 括號錯誤 (`{{{` vs `{{`, `}} }`); 控制結(jié)構(gòu)括號錯誤 (`{{%` vs `{%`); 變量名不匹配；在未解析數(shù)據(jù)上訪問屬性。
    *   **解決:** 修正 Jinja2 語法；確保模板變量名與輸入變量名**完全一致**；對列表/字典數(shù)據(jù)，**先用 CODE 解析**再傳入模板，并使用 `{% for %}` 訪問循環(huán)變量屬性 (`{{ part.name }}`)。

1.  獲取真實 API 信息:** 獲取真實的 IoT、CMMS、MES、ERP 系統(tǒng)的 API 詳細信息：
    
    *   **URL 端點 (Endpoint):** 每個系統(tǒng)提供數(shù)據(jù)的具體網(wǎng)址。
        
    *   **請求方法 (Method):** GET, POST, PUT, DELETE 等。
        
    *   **認證方式 (Authentication):** 如何驗證 Dify 的訪問權(quán)限？可能是 API Key (放在 Header 或 Query Param)、OAuth 2.0 Token (放在 Header)、用戶名密碼等。
        
    *   **請求參數(shù)/體 (Parameters/Body):** 如何指定要查詢的設(shè)備 ID、時間范圍、零件 ID 等？是在 URL 參數(shù)中，還是在 POST 請求的 Body 中？Body 的格式是 JSON、XML 還是其他？
        
    *   **響應(yīng)格式 (Response Format):** 真實系統(tǒng)返回的數(shù)據(jù)結(jié)構(gòu)是怎樣的？與模擬的 JSON 結(jié)構(gòu)是否一致？
        
2.  修改 Dify HTTP Request 節(jié)點:
    
    *   定位工作流中所有調(diào)用模擬 API 的 HTTP Request 節(jié)點 (`GET_IOT_DATA`, `GET_CMMS_DATA`, `GET_MES_DATA`, `GET_ERP_DATA`)。
        
    *   **更新 URL:** 將節(jié)點的 URL 字段替換為真實 API 的端點。
        
    *   **調(diào)整方法:** 根據(jù)真實 API 要求修改請求方法 (GET/POST 等)。
        
    *   **配置認證:** 在節(jié)點的 `Headers` 或 `Params` 部分添加必要的認證信息 (如 `Authorization: Bearer <token>`, `X-API-Key: <key>`)。
        
    *   **適配參數(shù)/體:** 根據(jù)真實 API 要求修改 `Params` 或 `Body` 的內(nèi)容和格式。
        
3.  適配數(shù)據(jù)解析 (關(guān)鍵步驟??):
    
    *   真實 API 返回的數(shù)據(jù)結(jié)構(gòu)**極有可能**與模擬 JSON 不同。
        
    *   因此，所有緊跟在 HTTP Request 節(jié)點之后的 `CODE` 節(jié)點（如解析 IoT 的 `CODE` 節(jié)點, `PARSE_ERP_DATA` 節(jié)點，以及可能需要為 CMMS/MES 新增的解析節(jié)點）**必須進行修改**。
        
    *   需要根據(jù)真實 API 返回的 JSON (或其他格式) 結(jié)構(gòu)，調(diào)整 Python 代碼中 `json.loads()` 之后訪問數(shù)據(jù)的方式（字典鍵名、列表索引、嵌套結(jié)構(gòu)等），以確保存儲到 Dify 輸出變量中的是后續(xù)節(jié)點期望的數(shù)據(jù)。
        
    *   **這是最容易出錯的環(huán)節(jié)，需要仔細比對真實 API 的響應(yīng)并耐心調(diào)試** `CODE` **節(jié)點的 Python 代碼。
        
4.  端到端測試:** 修改完成后，使用真實的設(shè)備 ID 或測試 ID 進行完整的端到端測試，驗證：
    
    *   是否能成功從所有真實系統(tǒng)中獲取數(shù)據(jù)。
        
    *   數(shù)據(jù)解析是否正確。
        
    *   LLM 節(jié)點接收到的上下文是否符合預(yù)期。
        
    *   整個流程是否能按預(yù)期運行。

告警通知: 在檢測到異常時，通過 HTTP 請求節(jié)點調(diào)用企業(yè)微信、釘釘、郵件等的 API 發(fā)送告警通知。

工單系統(tǒng)集成: 將 `SUGGESTIONS` 生成的維護建議通過 API 推送到 CMMS 系統(tǒng)，自動創(chuàng)建維護工單。