1. 目前概況與現況落差
- 規劃落差：原先系統僅針對「車用電池、家用儲能、高壓儲能」進行資料模型設計，未包含「堆高機」規格。
- 先前上雲定位：過去的上線僅驗證「通訊與連線能力」，非正式納入伺服器設備管理邏輯。
- 現階段折衷呈現：後端目前將堆高機識別為「家用儲能」，前端暫時顯示為「電池櫃」 UI。
2. 評估方案比較
| 方案 | 實作機制 | 適合情境 | 優點 | 關鍵風險 / 限制 |
|---|
| 方案 A：前端快速硬編碼 (Short-term) | 前端比對特規 Serial Number / 條碼，直接切換堆高機 UI | 僅適用於近期展覽 / Demo 展示 | 時程極短，無需動到後端資料庫與 API | 擴充性為零；條碼硬編碼易維護混淆；非真實資料邏輯 |
| 方案 B：後端設備模型重構 (Long-term) | 後端新增堆高機資料表，重構 API 識別，建立專屬數據模型 | 正式產品化、長期客戶應用 | 系統架構完整，資料流正確，利於後續擴充 | 開發時程較長；需韌體配合回傳 GPS 資料並修正 Spec |
| 方案 C：雙階段推進 (Hybrid) | 先執行方案 A 滿足展示時效，同步/後續推進方案 B | 有急迫展示需求，且該產品確定要產品化 | 兼顧展示時效與系統架構發展 | 總開發工時較高；需要管理兩階段的程式碼版本 |
3. 跨團隊依賴與技術備註 (Dependency & Spec)
- 韌體 (FW) 需求：即時定位與動態數據回傳需韌體將 GPS Payload 加入上報通信協定（Spec）。