充电桩小程序开发和充电桩系统开发遇到的问题

概述

碳达峰碳中和战略实施，新能源是一个大行业，电动车是实现汽车领域弯道超车的必然途径。充电桩及其配套产品和设施：一套完整的可商业化运营的充电桩SaaS服务系统，包含平台管理端、各级代理商端、充电桩小程序\APP车主用户端、维修人员端等几大系统，支撑充电桩运营企业的业务全流程发展。

接入充电桩流程：根据厂家协议文档的格式写代码，解析协议，然后分析，存储，并与后台交互。上传的内容有：开关电结果，充电过程数据。下发的有：开关电指令，时间同步指令。

——就这么简单。会者不难，难者不会

然而，凡事都不简单，不容易。

协议

有的厂家协议文档写的规范，有的却不是。

规范的文档，文字通顺，图例准确，流程正确，报文示例完整。反之不规范。

不过，绝大部分是不规范的，有很多实际情况是超出了协议文档的，换言之，只看协议文档，是干不了什么事的，一定要拿到真实报文。当然，真正的协议，真实报文也不是想要就能要到的。因为开发方是没话语权的，只能靠甲方。

交流

交流是最麻烦的。实际中，有甲方、甲A方（与甲方有深度战略合作，有直接指挥权）、厂家、开发方（笔者所在公司），每一方，有领导、小领导、员工（或是实施人员，或是监督专员，或是开发人员），这些排列组合非常多，每一角色对系统的理解不同，认知范畴不同，导致交流比较耗时。

比如，甲方要实现实现某功能，我看到议文档中没有这个功能的字段，厂家销售经理信誓旦旦说有，厂家开发人员也信誓旦旦说有，当然我也信誓旦旦说没有，后来当面拿文档看，发现厂家看到的与我看到的，不是同一个文档。这种情况不能怨天由人，但时间就白白耗掉了。（后来我脾气也上来了，延后一周才交货）

比如，甲方领导说11点到某地方与厂家人员调试，按时到之后，发现厂家技术人员在火车上，正在赶过来。到午饭时间，打电话问甲方，回复说厂家技术人员还在火车上，正在赶过来。各方对时间的观念不同，不能说谁对谁错，但白白浪费时间。

不同的角度在传递信息时会出现偏差，有一次，我方与甲A方约定在地点A调试，但厂家实施人员到了地点B，大家相互等待，因为A、B都是相同的站点，只是地点不同。

类似的事还有很多。

现场

理论上，甲方和厂家应该做好施工，搭建好网络环境后，才到我方入场调试。不过实情往往是甲方说已经准备好，要求我方与厂家方一起调试，结果要等厂家单独调试设备，连接网络，这样，一个上午过去了。

曾经遇到一次，厂家方怪我方没有接好网线，路由器没通电，当然，我方也是怪厂家方没搞好网络。实际是甲方搞的还是甲方请的施工队搞的，已经无从得知了。

当然，顶着烈日，坐着午休这种肉体上的事，相对来说，还能承受。

技术

协议

充电桩的协议主要关注2方面，一是协议的组成，包括字段及解释；二是流程，包括开关电，数据上传回应。协议的解析没有什么技术，协议一般分二进制或protobuf格式（当然，本质都是二进制），主流语言都可以进行解析，但不能将协议报文转换成字符串，再指定每个字段的长度进行解析，这样做太不专业了。应该封装一个读取类或使用函数进行处理，根据字符串（指定长度）、十六进制字符串、8位/16位/32位/64位长度、BCD码等封装为不同的函数，这样无须了解字段所处的偏移，只知道各字段的前后关系即可。

其中可能存在的坑，主要是协议文档语焉不详，比如，有的字段保留3个小数点，但实际要按4个小数点解析。此时需要厂家的介入，否则，死嗑只会浪费时间。对于协议一定扣细节，否则会有各种麻烦事产生。

至于流程，只能与实际硬件设备进行调试时才能确认，此时，最好记录所有的报文，分析各个报文，与文档核对。

问题

大小端

一定要留意大小端的问题，注意，不是所有的厂家都能准确理解“大小端”的，我曾经遇到反其道而行之的情况，当时花了很多时间。

字段值出错

字段的值可能会出现错误，比如时间字段，可能解析得到的秒数超过60，此时转换时间就会出错，因为很多语言会进行月份、时分秒的判断。比如结束充电时间比开始充电时间还早，这样得到的充电时长将为负数。

网络问题

网络问题亦十分麻烦，遇到过各种网络问题：

甲方的流量卡似乎没有管理一说，有很多次，白天或半夜全站设备离线，原来是流量卡欠费了，交费后一切正常。

有的站位于立交桥底，有时候信号不好，导致时连时断的情况发生。

有一次，厂家的设备无法连接服务器，经过反复测试验证，最后确认是厂家设备的网关不生效导致。

其它

有一次，甲方说，有司机反应车充不了电，怀疑系统有问题。此事比较严重，我方、甲方、厂家、电车方会聚一堂到现场调试，最后发现当电量小于30%时，只能充数分钟，之后自动关电，如此反复直到电量超过阈值后，恢复正常。厂家的结论是电车与电桩之间的握手问题，因为与我方无关，后事就不知道了。

元旦那天下午，甲方说系统不正常，无法登陆，后来得知是日志文件把服务器硬盘撑满了。此事闹得比较大，当晚领导集合所有开发人员讨论。后发函给甲方说明原由。那次有幸和同事去聆听甲方大领导训话。了解到我们的系统如果不正常会导致司机罢工，影响大领导仕途。

服务端

服务端主要考虑：如何快速更新服务，如何平衡负载。

经过考虑，使用pm2进行服务进程的管理，因为用pm2 reload可以快速重启，经过测试，能在1秒内完成重启。但是，电桩设备不一定能在1秒后重新连接。而且，大多数设备有心跳存活的机制，有的不会管socket是否断开，一定要经过4次心跳，每次30秒，硬生生将一个重连过程延长到100多秒（最终坚持要求厂家向甲方解释清楚此情况，否则会背锅）。

另外，pm2还可以平滑扩容，不过因为当前的量不大，无须使用此功能。

日志：使用log4js模块，每天备份压缩日志，保留90天日志备查。

邮件通知：起初，为了迅速了解设备情况，设备离线时会发邮件通知，没几天，发现邮件太多了，因为很多电桩经常离线又马上连接，此情况不影响充电，后来就取消邮件通知功能。

技术总结

根据自己在搜索到的知识点，对充电桩系统进行整理，仅为个人观点。

桩

不同充电桩厂家，其协议不同，基本是各自独立的。近年出了中电联标准（全称《电动汽车充换电服务信息交换 》），有厂家支持，也有厂家不支持。南网协议也有很多厂家在用，因为南网有能力定制协议。其协议似乎来自IEC 101或IEC 104。不过，对于不接触电力行业的人而言，协议比较难看懂，需要多方交叉查询。但是，即使是同一份南网协议，不同厂家实现上也略有差异。如同一数据的传递，此厂家使用此类型，彼厂家使用彼类型。协议要仔细研究。但是，即使仔细研究，也不一定就对，还需要看实际电桩上传的数据，因为协议文档是一回事，具体数据是另一回事。但是，即使看实际数据，也要仔细，同一厂家，不同时间的电桩，其软件版本不一定相同。厂家口头说是一回事，实际测试是另一回事。总体原则是：信自己，对厂家的文档、说明辩证对待。

电桩建站需要找地点、谈费用，拉电线，申请开电，安装桩，桩调试，接入平台调试，等。过程较复杂。注意，硬件设施部分一定要厂家方面人员调试，曾遇到过接线反的情况，还好在开电前检查一遍。（不同电源线颜色不同，对比左右电桩可得结论）

不同车对电流、电压需求不同，在开始充电过程中会获取需求值。有的电桩会先发起充电，测试是否OK，然后才真正充电。从数据可看到前期较低电压电流，接着慢慢提升。当然，不同设备，过程不同，数据不同。但，电桩与电动车之间是一定存在连接阶段的。有些电车充不了电，可能是电桩兼容性问题，只能换桩。最坏情况是，电车与电桩程序有bug，握手有问题，从而充不了电。

电桩有寿命，使用几年，有些模块可能老化了，充电慢或充不了电。

电桩可通过有线网络或无线网络接入服务器，根据地区、地点或天气，信号可能好可能不好。如立交桥底，偏远站点，等。

前端接入

根据各家协议编码接入，无捷径，只能硬编。最多可用分层思想，将协议接口转换为通用格式，以并集进行管理，没有的接口可留空，方便与后台对接。

同一站点，可用同一端口号（建议如此）。 不同站点，相同协议，也可用同一端口号。但不建议不同站点，不同厂家使用同一端口号。如此一来，管理较混乱。

如果条件允许，可在服务端用统一端口进行转发。但涉及面广，难度有点大。

前端编程可选C、C++、JAVA、NodeJS、Golang等语言，接入事项主要有TCP服务（或HTTP服务）、二进制数据解析等。从熟练程度、能否扩容、性能等方面考量。

缓存可用redis实现，对于永久存储数据，不建议在前端做。可统一在后台进行。

后台

后台语言可用C++、JAVA、NodeJS、Golang等语言。页面前端可用vue或其它框架。永久存储可选MySQL。后端语言与存储服务有大量的库供使用。

后台与前端通过json数据交互。可区分命令类（如开电、关电）、数据类（电压、电流数据）。

支付可对接微信支付、支付宝、银联等，但需要申请开通。前两者较容易申请。注意要准备好域名。

为对电桩进行资产管理，接入的电桩均需在后台登记，包括厂家名、设备ID、站点等信息。登记后为合法，在程序中建议判断设备。

金钱、财务管理方面，要严格测试

其它

目前一般电桩接入的服务器在公网中，每天均有尝试登陆服务器、攻击数据库的行为。修改默认端口，开启登陆白名单、删除无用服务，加强密码，及时补漏洞，可以减少风险。当然，选一个好的服务商，也是十分必要。

总结

充电桩小程序不是一个简单的互联网性质小程序，是互联网+物联网，软硬件一体+TCP/IP Socket通信，还有现场实施，包括人员、设备管理、项目多方沟通协商才能做成的东西，要慎重。