缺口是真實存在的
2025 年全球電動車銷量突破 2000 萬輛。按大多數指標衡量，充電基礎設施都沒跟上。電動車與公共充電點的比值在各地區差異極大——有些市場供給充足，有些明顯建設不足。
問題並不純粹是數量。更是可靠性。一台三成時間處於離線狀態的充電樁，其實算不上這個網路的一部分。美國和歐洲的研究一再顯示，任一時刻都有 10%–25% 的公共充電樁處於無法使用的狀態，原因從網路連線問題、支付系統故障，到固件缺陷不等。
最後這一項，是我們真正能修的。
軟體這一層
現代充電樁是相當複雜的聯網設備。它跑 Linux（更簡單的硬體上跑 FreeRTOS），講多種協定，處理支付，管理熱工況，還要和雲端後台通訊。這套軟體堆疊的體量不小。
然而留給固件開發者的工具鏈卻一直落在後面。充電樁這個行業歷來由硬體公司主導，軟體是後來補上的。結果就是碎片化、常常帶缺陷的固件——恰恰造成了整個行業想解決的那些可靠性問題。
這件事正在改變。新一代公司在用「軟體優先」的思路做充電產品。他們招的是有嵌入式 Linux、分散式系統和網路背景的工程師，而不只是電力電子出身的人。他們寫測試、跑 CI 流水線，把軟體當成一等交付物。
協定碎片化（基本上）解決了
幾年前，互通性是個真問題。不同的 CSMS 廠商對 OCPP 的實作各不相同；對著一家後台認證過的充電樁，換一家未必能乾淨地跑通。
OCPP 1.6 配 JSON 綁定（OCPP-J）已經成為事實上的基線。只要你把 OCPP 1.6-J 支援對了，現場絕大多數 CSMS 部署你都能對接。OCPP 2.0.1 在新部署裡勢頭漸起，尤其是那些需要更好的智慧充電、ISO 15118（Plug&Charge）和更強安全性的場景——但 1.6 短期內不會消失。
開發者在做什麼
眼下最有意思的工作集中在幾個方向：
智慧充電與負載管理：根據電網狀況、本地負載和電價訊號動態調整充電功率。這要求 CSMS、充電樁，有時還有建築能源管理系統之間緊密整合。
Plug&Charge（ISO 15118）：透過車輛憑證自動完成認證。不用 App，不用 RFID 卡，車和樁直接協商。實作相當複雜，但使用者體驗上的回報很可觀。
雙向充電（V2G/V2H）：把車載電池當作電網儲能或家庭備電。這需要車輛與充電樁兩端的硬體支援，也需要 OCPP 2.1——第一個內建雙向充電與電網（DER）控制的版本。
可靠性工具：監控、診斷和遠端固件升級系統。當營運商規模擴到數千台樁，人工介入就不現實了。
開發者的機會
如果你是開發者，又對真正要緊的基礎設施有興趣，電動車充電是當下比較有意思的領域之一。問題是真實的，規模在漲，而許多在位產品的軟體品質門檻——說實話——並不高。把活做得明顯更好，是有空間的。
我們在做工具，幫這個領域的開發者走得更快、交付更可靠的固件。TestPilot 是第一個；隨後是 SimPilot（模擬一台充電樁）、ChargePilot（營運一個網路）和 HubPilot（OCPI 漫遊，開發中），它們都跑在同一套 OCPP 引擎上。