充电桩前端对接的一点总结

笔者近一年来接触了大约八、九家不同品牌的充电桩协议,主要做协议接入,并与后台通信的工作。本文对接入进行一些总结。

概述

其实接入充电桩很简单的:根据厂家协议文档的格式写代码,解析协议,然后分析,存储,并与后台交互。上传的内容有:开关电结果,充电过程数据。下发的有:开关电指令,时间同步指令。
——就这么简单。

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

协议

有的厂家协议文档写的规范,有的却不是。
规范的文档,文字通顺,图例准确,流程正确,报文示例完整。反之不规范。
不过,绝大部分是不规范的,有很多实际情况是超出了协议文档的,换言之,只看协议文档,是干不了什么事的,一定要拿到真实报文。当然,真正的协议,真实报文也不是想要就能要到的。因为开发方是没话语权的,只能靠甲方。

交流

交流是最麻烦的。实际中,有甲方、甲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天日志备查。
邮件通知:起初,为了迅速了解设备情况,设备离线时会发邮件通知,没几天,发现邮件太多了,因为很多电桩经常离线又马上连接,此情况不影响充电,后来就取消邮件通知功能。

外包不易,希望下次找工作不会重蹈覆辙了。

李迟 2019.9.30 周一