笔者近一年来接触了大约八、九家不同品牌的充电桩协议，主要做协议接入，并与后台通信的工作。本文对接入进行一些总结。
概述
其实接入充电桩很简单的：根据厂家协议文档的格式写代码，解析协议，然后分析，存储，并与后台交互。上传的内容有：开关电结果，充电过程数据。下发的有：开关电指令，时间同步指令。
——就这么简单。
然而，凡事都不简单，不容易。
协议
有的厂家协议文档写的规范，有的却不是。
规范的文档，文字通顺，图例准确，流程正确，报文示例完整。反之不规范。
不过，绝大部分是不规范的，有很多实际情况是超出了协议文档的，换言之，只看协议文档，是干不了什么事的，一定要拿到真实报文。当然，真正的协议，真实报文也不是想要就能要到的。因为开发方是没话语权的，只能靠甲方。
交流
交流是最麻烦的。实际中，有甲方、甲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、站点等信息。登记后为合法，在程序中建议判断设备。
金钱、财务管理方面，不熟悉。
其它
目前一般电桩接入的服务器在公网中，每天均有尝试登陆服务器、攻击数据库的行为。修改默认端口，开启登陆白名单、删除无用服务，加强密码，及时补漏洞，可以减少风险。当然，选一个好的服务商，也是十分必要。
参考
外包不易，希望下次找工作不会重蹈覆辙了。
李迟 2019.9.30 周一
