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

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

概述

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

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

协议

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

交流

交流是最麻烦的。实际中,有甲方、甲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、站点等信息。登记后为合法,在程序中建议判断设备。

金钱、财务管理方面,不熟悉。

其它

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

参考

https://wenku.baidu.com/view/50bb9ac5227916888586d73a.html
外包不易,希望下次找工作不会重蹈覆辙了。

李迟 2019.9.30 周一

展开阅读全文
©️2020 CSDN 皮肤主题: 技术工厂 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值