1. 現狀概述與痛點分析
目前軟韌體端在藍牙通訊對接上，依賴「靜態 Modbus 點位表（Word/Excel）」進行協作，導致以下惡性循環：
- 規格漂移（Drift）：韌體程式邏輯與文件規格無法自動同步，造成資訊不一致。
- 解析脆弱性（Fragility）：軟體端試圖透過 Python 或手動方式解析 Word，因格式排版變動頻繁，導致解析工具維護成本高於產品本身開發。
- 邊界責任模糊：當數據數值錯誤時，雙方陷入長期的「除錯對質」，缺乏明確的驗收合約。
2. 為什麼 Word/Excel 作為規格是不合格的？
在現代工業物聯網（IIoT）架構下，文件應區分為「人閱讀文件」與「機器閱讀合約」：
- 非結構化（Unstructured）：Word 格式無強制規範，隨意插入的空格或儲存格合併，對程式來說是毀滅性的輸入錯誤。
- 無法自動驗證（No Validation）：Word 無法告知程式「此地址是否漏寫」或「資料型態是否正確」，錯誤只能在產品運作時才暴露。
- 維護冗餘（Redundant Effort）：軟體端為了「解析 Word」而開發的 Parser，是為了填補流程缺失而產生的「無效技術債」。
3. 推薦架構：Modbus (傳輸) + JSON (定義)
建議採用 「Modbus 物理傳輸 + JSON 結構化對接」 的混合模式，將「資料傳輸」與「資料定義」解耦。
核心規則：
- JSON 作為唯一合約（Source of Truth）：所有點位異動以 JSON 為準，而非 Excel。
- 機器可讀（Machine-Readable）：JSON 必須符合預先定義的 Schema，確保資料型態、位址、換算係數（Multiplier）無歧義。
- 韌體端生產（Producer）：由韌體端（最了解設備特性者）維護 JSON 設定檔，並建議在編譯流程中自動導出。
- 軟體端消費（Consumer）：開發通用解析引擎（Parser），讀取 JSON 後自動生成介面邏輯，實現 App 動態擴充。
4. 效益與影響評估
| 比較維度 | 原有模式 (Word/Excel) | 推薦模式 (JSON 結構化) |
|---|---|---|
| 維護成本 | 高（軟體需隨規格頻繁改碼） | 低（軟體僅需更新配置檔） |
| 錯誤率 | 高（人工輸入、解析錯誤） | 低（程式自動檢查 Schema） |
| 擴充性 | 差（需重編譯 App） | 極高（線上下載配置即可） |
| 除錯邊界 | 模糊（互相推託） | 清晰（直接核對 JSON 與 Log） |
5. 執行步驟建議
- 第一步：建立標準 Schema：軟體端定義一份範本（包含地址、Data Type、Multiplier 等必要欄位）。
- 第二步：試辦 POC：選定一個簡單的模組，由韌體端提供 JSON，軟體端驗證解析引擎的準確性。
- 第三步：自動化整合：協助韌體端將「產出 JSON」整合進現有的 Build 流程，實現韌體改版即同步更新對接合約。