文档更改颂盛

在2020/12/25 14:13上被chinyee he修改
从版本< 17.2 >
由yuandong he编辑
在2019/11/12 16:23上
到版本
由yuandong he编辑
在2019/12/04 11:02上
< >
修改评论 该版本没有评论

Summary

Details

Page properties
Content
... ... @@ -3,6 +3,67 @@
3 3  {{/box}}
4 4  
5 5  (% class="wikigeneratedid" %)
6 += gdss_case#5_201911113 =
7 +
8 +广州颂盛旧系统平台
9 +日期：2019-12-04
10 +桩站名称：塘坑站点、大岗站点、桥南站点、
11 +手机号：
12 +订单号：
13 +充电桩号：
14 +充电枪号： 
15 +时间：2019年11月份
16 +
17 +现场网络连接状态：正常 
18 + 异常状态：金额、峰、平、谷值都为0 
19 +问题描述：今天早上接到客户的反应颂盛的三个站点有几条充电日报表金额、峰、平、谷值都为0，见表格下：
20 +
21 +20191108112557047049
22 +20191109045929266559
23 +20191112002225771301
24 +20191116000001501830
25 +20191125001902046919
26 +20191127001635518809
27 +20191106044333115970
28 +20191109000104273153
29 +
30 +~-~-跟踪
31 +
32 +【YD】：这些单都为“账单丢失”，但手动修正里有部分单的修正电量过大。
33 +
34 +~-~-解决:
35 +状态（√表示选定 ）： 已解决 | 处理中 | 暂搁置
36 +
37 +售后（跟单）工程师：施文俊 YD
38 +
39 +
40 += gdss_case#5_201911113 =
41 +
42 +广州颂盛旧系统充电平台
43 +
44 +日期：2019-11-13
45 +桩站名称：
46 +手机号：
47 +订单号：20191108112557047049/20191109000104273153/20191109045929266559
48 +充电桩号：
49 +充电枪号：
50 +开始充电时间：
51 +现场网络连接状态：正常
52 +异常状态：
53 +问题描述：现在广州颂盛大岗站、塘坑站出现峰平谷值为零的现象
54 +
55 +~-~-跟踪
56 +
57 +【令】：排查结果如下，都是充电桩上送的电表读数异常所致。颂盛的桩是 “罗宾森”桩， 这个电表读数异常的问题，还存在。
58 +
59 +[[image:1573633992288-441.png]]
60 +
61 +~-~-解决:
62 +状态（√表示选定 ）： √ 已解决 | 处理中 | 暂搁置
63 +
64 +售后（跟单）工程师：施文俊  何倩怡
65 +
66 +
6 6  = gdss_case#6_20191112 =
7 7  
8 8  广州颂盛旧系统平台
... ... @@ -22,6 +22,18 @@
22 22  ~-~-跟踪
23 23  
24 24  【令】：已转研发
86 +【shi】： 罗宾森桩的问题看来是比较多啊。见附件 [[attach:罗宾森_20191112001934329341问题排查.log||target="_blank"]]，罗宾森解释是RS485丢包造成的。 目前暂时由后台人工处理了， 用设备账单来计费。
87 +to 金凯瑞许总：
88 +请关注罗宾森桩程序目前的问题。
89 +联想到贵司伙伴即将在深圳运营，不禁有些担忧。按照我的经验，深圳市社会车辆 充电业务量的数量级是其他城市几倍，用户对充电数据精准性不是公交充电能比的（仅月底看一次数据。）
90 +附件是我司技术对问题账单分析，我按照通俗易懂方式给您解释如下：
91 +1）背景知识：计算机需要按照约定的协议严格执行协议流程。
92 +2）类比举例：
93 +吃饭需要5步，即：1，2，3，4，5。 
94 +小明实际吃饭步骤：1,3,4,5  或 1,3,2,4,5 或 1,2,2,2,3,4,5  等类似不按约定协议执行。
95 +3）因为第2项的原因，充电桩在一些情况下（蒙混过关）看来是完成充电了，因为运营环境的复杂，实际上会很大概率出现各种无法预期的异常。
96 +4）第2项 这个问题  从第一个罗宾森桩投入运营上线至今似乎一直存在，未彻底解决。看如何彻底解决。
97 +5）如果 大家认同  运营稳定排第一位。 所谓 RS485 丢包造成，是否可以更换 相应的模块配件。
25 25  
26 26  ~-~-解决:
27 27  状态（√表示选定 ）： 已解决 | 处理中 | 暂搁置
1573633992288-441.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.Chinyee
Size
... ... @@ -1,0 +1,1 @@
1 +29.4 KB
Content
罗宾森_20191112001934329341问题排查.log
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.ShiChuck
Size
... ... @@ -1,0 +1,1 @@
1 +1.2 KB
Content
... ... @@ -1,0 +1,40 @@
1 +充电桩:44011300040000200061 枪号:2 账单ID:20191112001934329341
2 +61号桩2号枪发起密码充电鉴权:
3 +11-12 00:19:34.869, 14
4 +11-12 00:19:35.848, 15
5 +11-12 00:19:39.044, 16
6 +
7 +启动充电...
8 +11-12 00:19:40.088, 24
9 +11-12 00:19:40.090, 20
10 +
11 +该桩没有回复消息21, 在启动充电未完成的情况下:
12 +
13 +于11-12 00:19:40.148, 连接断开,充电桩离线
14 +
15 +该桩发起新的连接后，在没有进行启动消息流程及上送心跳(后台判断该桩状态此时为“离线”)的情况, 就直接重发启动充电消息(多次)
16 +11-12 00:19:53.616, 24
17 +11-12 00:20:07.117, 24
18 +11-12 00:20:50.969, 24
19 +...
20 +
21 +直到 11-12 00:23:19.308,5 该枪上送心跳(状态空闲)
22 +
23 +然后该桩再次发起启动充电...
24 +11-12 00:23:22.029,24
25 +11-12 00:23:22.030,20
26 +
27 +11-12 00:23:35.529,24
28 +11-12 00:23:35.530,20
29 +
30 +等待充电桩回复消息21,未等到...
31 +
32 +后台在4分钟后发起停止充电请求(后台逻辑)，结束本次充电事务
33 +11-12 00:23:36.398,12
34 +
35 +
36 +但11-12 00:23:40.249,21 (这时桩回复了21，开始充电了...)
37 +
38 +所以结果是:
39 +1、在“11-12 00:23:36.398”，后台判断该充电事务结束了,无充电.
40 +2、这时充电桩开始充电...