从版本< 16.3 >
shi chuck编辑
在2019/10/31 18:22上
到版本
yuandong he编辑
在2019/12/04 15:17上
< >
修改评论 该版本没有评论

Summary

Details

Page properties
文档作者
... ... @@ -1,1 +1,1 @@
1 -XWiki.ShiChuck
1 +XWiki.yuandong
Content
... ... @@ -2,6 +2,103 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 += gdss_case#6_20191204 =
6 +
7 +广州颂盛旧系统平台
8 +日期:2019-12-04
9 +桩站名称:塘坑站点、大岗站点、桥南站点、
10 +手机号:
11 +订单号:
12 +充电桩号:
13 +充电枪号: 
14 +时间:2019年11月份
15 +\\现场网络连接状态:正常 
16 + 异常状态:金额、峰、平、谷值都为0 
17 +问题描述:今天早上接到客户的反应颂盛的三个站点有几条充电日报表金额、峰、平、谷值都为0,见表格下:
18 +
19 +20191108112557047049
20 +20191109045929266559
21 +20191112002225771301
22 +20191116000001501830
23 +20191125001902046919
24 +20191127001635518809
25 +20191106044333115970
26 +20191109000104273153
27 +
28 +~-~-跟踪
29 +
30 +【YD】:这些单都为“账单丢失”,但手动修正里有部分单的修正电量过大。
31 +
32 +~-~-解决:
33 +状态(√表示选定 ): 已解决 | 处理中 | 暂搁置
34 +
35 +售后(跟单)工程师:施文俊 YD
36 +
37 +
38 += gdss_case#5_201911113 =
39 +
40 +广州颂盛旧系统充电平台
41 +
42 +日期:2019-11-13
43 +桩站名称:
44 +手机号:
45 +订单号:20191108112557047049/20191109000104273153/20191109045929266559
46 +充电桩号:
47 +充电枪号:
48 +开始充电时间:
49 +现场网络连接状态:正常
50 +异常状态:
51 +问题描述:现在广州颂盛大岗站、塘坑站出现峰平谷值为零的现象
52 +
53 +~-~-跟踪
54 +
55 +【令】:排查结果如下,都是充电桩上送的电表读数异常所致。颂盛的桩是 “罗宾森”桩, 这个电表读数异常的问题,还存在。
56 +
57 +[[image:1573633992288-441.png]]
58 +
59 +~-~-解决:
60 +状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置
61 +
62 +售后(跟单)工程师:施文俊  何倩怡
63 +
64 +
65 += gdss_case#6_20191112 =
66 +
67 +广州颂盛旧系统平台
68 +日期:2019-11-12
69 +桩站名称:广州颂盛桥南充电站
70 +手机号:
71 +订单号:20191112001934329341
72 +充电桩号:44011300040000200061
73 +充电枪号: 
74 +开始充电时间:2019-11-12 00:23:38
75 +结束时间:2019-11-12 03:50:36
76 +现场网络连接状态:正常 
77 + 异常状态:充电量与平台不符
78 +
79 +[[image:1573546978385-211.png||height="334" width="705"]]
80 +
81 +~-~-跟踪
82 +
83 +【令】:已转研发
84 +【shi】: 罗宾森桩的问题看来是比较多啊。见附件 [[attach:罗宾森_20191112001934329341问题排查.log||target="_blank"]],罗宾森解释是RS485丢包造成的。 目前暂时由后台人工处理了, 用设备账单来计费。
85 +to 金凯瑞许总:
86 +请关注罗宾森桩程序目前的问题。
87 +联想到贵司伙伴即将在深圳运营,不禁有些担忧。按照我的经验,深圳市社会车辆 充电业务量的数量级是其他城市几倍,用户对充电数据精准性不是公交充电能比的(仅月底看一次数据。)
88 +附件是我司技术对问题账单分析,我按照通俗易懂方式给您解释如下:
89 +1)背景知识:计算机需要按照约定的协议严格执行协议流程。
90 +2)类比举例:
91 +吃饭需要5步,即:1,2,3,4,5。 
92 +小明实际吃饭步骤:1,3,4,5  或 1,3,2,4,5 或 1,2,2,2,3,4,5  等类似不按约定协议执行。
93 +3)因为第2项的原因,充电桩在一些情况下(蒙混过关)看来是完成充电了,因为运营环境的复杂,实际上会很大概率出现各种无法预期的异常。
94 +4)第2项 这个问题  从第一个罗宾森桩投入运营上线至今似乎一直存在,未彻底解决。看如何彻底解决。
95 +5)如果 大家认同  运营稳定排第一位。 所谓 RS485 丢包造成,是否可以更换 相应的模块配件。
96 +
97 +~-~-解决:
98 +状态(√表示选定 ): 已解决 | 处理中 | 暂搁置
99 +
100 +售后(跟单)工程师:施文俊 YD
101 +
5 5  = gdss_case#5_20191031 =
6 6  
7 7  
... ... @@ -98,7 +98,7 @@
98 98  
99 99  售后(跟单)工程师:施文俊  何倩怡
100 100  
101 -= =
198 += =
102 102  
103 103  = gdss_case#2_20190927 =
104 104  
... ... @@ -164,5 +164,3 @@
164 164  状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置
165 165  
166 166  售后(跟单)工程师:施文俊
167 -
168 -
1573546978385-211.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.yuandong
Size
... ... @@ -1,0 +1,1 @@
1 +191.9 KB
Content
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、这时充电桩开始充电...