EMS

背景¶

本票是 #1518 的子票，來源為 2026-09-28 對 MeterValues 第二～第五階段實作的 Astra 程式審查。該實作目前只存在主要 workspace，尚未部署至 A17；A17 已套用的第一階段複合索引不受本票影響。

工作位置：

• EMS workspace：/Users/ken/Documents/workspace/workspace_cloudlink/ems
• EMS branch：feature/redmine-1517-ocpp-liveness
• java/charge_point 為獨立 repository，使用相同 branch 名稱
• 直接使用主要 workspace，不建立 worktree
• 未經 Ken 指示不得部署或重啟案場服務

問題¶

新增的即時計費使用相鄰兩筆 MeterValue 直接呼叫 calculateIncrement(previous, current)。原本完整歷史計費還會處理同 timestamp、10 Wh 容許差異、短暫負增量、跨費率時段及單位換算；兩點式增量無法判斷讀值短暫下降後是否恢復。

重現資料：

611010 → 611000 → 611070 Wh

原有完整計費會排除中間 10 Wh 短暫下降，正確用量為 60 Wh；新 cache 忽略負區段，卻把 cursor 推進到 611000，下一段計成 70 Wh。每 kWh 3 元時，完整計費為 0.18 元，新流程為 0.21 元。

影響¶

• 進行中交易的 costPredict 可能偏高。
• 增量結果與 StopTransaction／月結／人工重算的完整歷史計費不一致。
• 若 cache 忽略 ERROR／PENDING_DATA 仍推進 cursor，錯誤會留在後續所有即時估算。

相關程式¶

• java/ems_branch/.../LiveTransactionCostService.java
• java/ems_branch/.../billing/MeterValueTariffCalculationService.java

建議修正¶

• 即時計費與完整計費共用正規化、同 timestamp 調和、負增量調和及區段計算規則，不維護第二套簡化規則。
• Cache 保留足以判斷短暫下降的尾端原始讀值，至少包含最近三個點。
• 尚未確認的最後區段保持 pending；下一點到達後再決定是否納入已確認費用。
• 遇到 ERROR／PENDING_DATA 時不得把未能安全計價的讀值當作已完整處理。
• 無法安全局部計算時標記 dirty，下一次從完整歷史重建。

驗收條件¶

1. 上述三筆資料逐筆到達時，最後結果為 60 Wh／0.18 元。
2. 同樣資料一次補送、cache 清除重建、Branch 重啟重建時結果皆相同。
3. 同 timestamp 調和、10 Wh 容許值、負增量、Wh／kWh 與跨費率規則均與完整計費一致。
4. ERROR／PENDING_DATA 不得被當成成功區段永久推進 cursor。
5. 正式帳務仍使用完整歷史計費，不得為配合新 cache 改變既有帳務規則。

重現¶

python3 test_report/evidence/1518-review/run_one.py negative-spike

審查時預期 0.18 元、實際 0.21 元，案例以 AssertionError 結束。