充放電軟體架構思考

1. 理想架構梳理

1. 充放電行為
   • 以 API 命令為主，Web 會串接 Heartbeat WebSocket 來確認與阿梅（Py Server）的連接狀況，如斷線立即觸發前端 UI 通知與安全保護。
2. 設備心跳顧慮
   • Heartbeat Websocket 參考：以固定頻率回復簡單 Response 確認無斷線，反應速度優於 API。建立兩條獨立監測通道以精準區分斷線情境：
     • 情境 A（Web <-> Py Server 斷線）：伺服器斷線，觸發自動保護機制，按預設排程與安全保護點運作。
     • 情境 B（Py Server <-> 設備斷線）：系統尚存但失去設備控制，需透過 Web 推播 alert [問題一]
3. 應用端架構
   • 阿梅架設 Py Server 負責 Static Web、API、機體通訊。
   • 網頁採用 Vue，資料夾位置與名稱存於本地，支援本地存取資料表。
   • 數據存取架構：
     • 目前規劃數據儲存於 VPS1，資料流傳輸途徑需要額外設立 [問題二]
   • 設備：(Measurement) Hioki BT3563A + (Power) ITECH IT-M3912C-80-240
4. 安全性考量
   • Py Server 須具備至少 50 ms/次 的數據採集頻率（#重點測試項目）[問題三]：
     • 與設備間的連線狀態 (Heartbeat / Ping)
     • 充放電累積時間
     • 充放電端即時數據（電壓、電流、功率）
     • (待討論延伸監控項目)

---

2. 已知問題與解決方案彙整

1. 問題一：設備與 Py Server 斷線時的現場與遠端告警機制（對接架構 1-2 情境 B）
   • 問題脈絡：當 Py Server 運作正常但與機體通訊中斷時，Web 介面需即時接獲通知，同時現場可能需要實體告警設備（如蜂鳴器、警示燈）。
   • 解決方案：
     • 軟體端：Py Server 在監測到機體 Timeout 時，主動向 Vue 發送 EVENT_DEVICE_DISCONNECTED WebSocket 廣播，強制彈出告警視窗。
     • 硬體/現場端：Survey 設備的硬體鎖，並測試觸發。
2. 問題二：VPS1 數據存取的網路通道與 API 路由規劃（對接架構 1-3 數據存取）
   • 問題脈絡：VPS1要開設新Docker或在原本的Docker開Port，server-dev就不會是為了ems建立，開設新的也會造成困難。
   • 解決方案：
     • 方案一：建立在VPS2，260812_1425測試可以
3. 問題三：目前Hioki BT3563A量測內阻，恐怕達不到50ms的目標（對接架構 1-4 數據存取）
   • 問題脈絡：目前通訊利用RS232 ( Hioki BT3563A )，需額外測試通訊速度，如達不到需求需增加解決方案。
   • 解決方案：
     • 方案一：用另外通訊口進行通訊 LAN 介面利用 TCP/IP 串接，需額外測試開發。
     • 方案二：保護點須跟使用人員教育好，Range要拉大一點。