从版本< 22.6 >
yuandong he编辑
在2020/01/15 11:57上
到版本
yuandong he编辑
在2019/11/12 16:22上
< >
修改评论 上传新附件1573546978385-211.png

Summary

Details

Page properties
Content
... ... @@ -2,157 +2,6 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 -= gdss_case#8_20200115 =
6 -
7 -问题描述:旧平台
8 -1.吴小英说他误修复了几张异常账单,希望把那几张单改回异常状态。
9 -
10 -2.修复后报表里多了这几张单,颂盛的客人那边会出现前后报表不一致的情况。他想避免这情况
11 -
12 -3.旧平台上他反应未修复的账单也能在报表看到20200108165713818444 20200111022016826908 这两个账单是没修复过的
13 -
14 -~-~-跟踪
15 -
16 -【YD】:
17 -
18 -1)2)已修复的,我们不能随意修改客户数据,如果客人问起来您需要向他们解释。
19 -3)颂盛这边一直都是配置成允许异常账单先结算扣款,后续人工修复再补扣,所以报表能看到
20 -
21 -~-~-解决:
22 -状态(√表示选定 ): 已解决 | 处理中 | 暂搁置
23 -
24 -售后(跟单)工程师:施文俊 YD
25 -
26 -= gdss_case#7_20200113 =
27 -
28 -问题描述:
29 -
30 -颂盛旧系统平台
31 -日期:2020-01-13
32 -桩站名称:颂盛站点
33 -手机号:
34 -订单号:20200113131916994301、20200113130454355822、20200113130336691650、20200113130240664036、20200113125312202217、20200113125311761057、20200113125203914204、20200113124854037470、20200113124637079267、20200113124544419307、20200113123331114379、20200113123029340160、20200113122916302241、20200113122040542106、20200113120748494182、20200113120300119547、20200113115846103652、20200113115828334527、20200113114219467743、20200113113813352135
35 -充电桩号:44011300040000200055、、44011300040000250003、44011300040000240001、44011300040000210006、44011300040000200085、44011300040000200054、44011300040000210005、44011300040000200083、44011300040000240002、44011300040000200053、44011300040000200093
36 -充电枪号: 
37 -充电时间:
38 -结束时间:
39 -现场网络连接状态:正常 
40 - 异常状态:充电电量与平台不符
41 -问题描述:充电电量与平台不符,请帮忙查看一下是什么原因,见下图:
42 -
43 -[[image:1578900456181-994.png||height="469" width="942"]]
44 -
45 -~-~-跟踪
46 -
47 -【YD】:转研发确认是否与gdss_case#6_20191204的原因一致。
48 -【令技术】:以上账单中出现的“充电电量与平台不符”的异常,  都是由于充电桩在充电前上送心跳的电表总读数均为0, 启动充电后,电表总读数变为一个较大的值 造成的 计算异常。
49 -
50 -~-~-解决:
51 -状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置
52 -
53 -售后(跟单)工程师:施文俊 YD
54 -
55 -= gdss_case#6_20191204 =
56 -
57 -广州颂盛旧系统平台
58 -日期:2019-12-04
59 -桩站名称:塘坑站点、大岗站点、桥南站点、
60 -手机号:
61 -订单号:
62 -充电桩号:
63 -充电枪号: 
64 -时间:2019年11月份
65 -\\现场网络连接状态:正常 
66 - 异常状态:金额、峰、平、谷值都为0 
67 -问题描述:今天早上接到客户的反应颂盛的三个站点有几条充电日报表金额、峰、平、谷值都为0,见表格下:
68 -
69 -20191108112557047049
70 -20191109045929266559
71 -20191112002225771301
72 -20191116000001501830
73 -20191125001902046919
74 -20191127001635518809
75 -20191106044333115970
76 -20191109000104273153
77 -
78 -~-~-跟踪
79 -
80 -【YD】:这些单都为“账单丢失”,但手动修正里有部分单的修正电量过大。
81 -
82 -【niewei】20191205 出现几万度电的情况, 是由于罗宾森桩的电表读数异常造成的。  需要人工处理。
83 -
84 -[[image:1575445987388-997.png||height="365" width="842"]]
85 -
86 -~-~-解决:
87 -状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置
88 -
89 -售后(跟单)工程师:施文俊 YD
90 -
91 -
92 -= gdss_case#5_201911113 =
93 -
94 -广州颂盛旧系统充电平台
95 -
96 -日期:2019-11-13
97 -桩站名称:
98 -手机号:
99 -订单号:20191108112557047049/20191109000104273153/20191109045929266559
100 -充电桩号:
101 -充电枪号:
102 -开始充电时间:
103 -现场网络连接状态:正常
104 -异常状态:
105 -问题描述:现在广州颂盛大岗站、塘坑站出现峰平谷值为零的现象
106 -
107 -~-~-跟踪
108 -
109 -【令】:排查结果如下,都是充电桩上送的电表读数异常所致。颂盛的桩是 “罗宾森”桩, 这个电表读数异常的问题,还存在。
110 -
111 -[[image:1573633992288-441.png]]
112 -
113 -~-~-解决:
114 -状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置
115 -
116 -售后(跟单)工程师:施文俊  何倩怡
117 -
118 -
119 -= gdss_case#6_20191112 =
120 -
121 -广州颂盛旧系统平台
122 -日期:2019-11-12
123 -桩站名称:广州颂盛桥南充电站
124 -手机号:
125 -订单号:20191112001934329341
126 -充电桩号:44011300040000200061
127 -充电枪号: 
128 -开始充电时间:2019-11-12 00:23:38
129 -结束时间:2019-11-12 03:50:36
130 -现场网络连接状态:正常 
131 - 异常状态:充电量与平台不符
132 -
133 -[[image:1573546978385-211.png||height="334" width="705"]]
134 -
135 -~-~-跟踪
136 -
137 -【令】:已转研发
138 -【shi】: 罗宾森桩的问题看来是比较多啊。见附件 [[attach:罗宾森_20191112001934329341问题排查.log||target="_blank"]],罗宾森解释是RS485丢包造成的。 目前暂时由后台人工处理了, 用设备账单来计费。
139 -to 金凯瑞许总:
140 -请关注罗宾森桩程序目前的问题。
141 -联想到贵司伙伴即将在深圳运营,不禁有些担忧。按照我的经验,深圳市社会车辆 充电业务量的数量级是其他城市几倍,用户对充电数据精准性不是公交充电能比的(仅月底看一次数据。)
142 -附件是我司技术对问题账单分析,我按照通俗易懂方式给您解释如下:
143 -1)背景知识:计算机需要按照约定的协议严格执行协议流程。
144 -2)类比举例:
145 -吃饭需要5步,即:1,2,3,4,5。 
146 -小明实际吃饭步骤:1,3,4,5  或 1,3,2,4,5 或 1,2,2,2,3,4,5  等类似不按约定协议执行。
147 -3)因为第2项的原因,充电桩在一些情况下(蒙混过关)看来是完成充电了,因为运营环境的复杂,实际上会很大概率出现各种无法预期的异常。
148 -4)第2项 这个问题  从第一个罗宾森桩投入运营上线至今似乎一直存在,未彻底解决。看如何彻底解决。
149 -5)如果 大家认同  运营稳定排第一位。 所谓 RS485 丢包造成,是否可以更换 相应的模块配件。
150 -
151 -~-~-解决:
152 -状态(√表示选定 ): 已解决 | 处理中 | 暂搁置
153 -
154 -售后(跟单)工程师:施文俊 YD
155 -
156 156  = gdss_case#5_20191031 =
157 157  
158 158  
... ... @@ -249,7 +249,7 @@
249 249  
250 250  售后(跟单)工程师:施文俊  何倩怡
251 251  
252 -= =
101 += =
253 253  
254 254  = gdss_case#2_20190927 =
255 255  
... ... @@ -316,21 +316,4 @@
316 316  
317 317  售后(跟单)工程师:施文俊
318 318  
319 -
320 -~#~##番禺项目汇报-20180724
321 -人员:
322 - 罗宾森售后
323 - 金凯瑞工程人员、项目经理、平台管理员
324 - 令狐充平台工程师
325 - 番禺场站公交负责人、运维人员
326 -\\阶段性成果:
327 - a、介绍平台功能和基本使用情况。客户运维、金凯瑞平台运维和令狐充运维 建微信群 计划初期对运营进行支撑和维护。
328 - b、目前支持站点密码为场站之车辆进行充电。
329 - c、少量电桩完成平台接入,并通过公交充电测试。其余待网络、电力设备就绪后逐个接入平台。
330 -
331 -
332 -联调之问题汇总:
333 -1、桩的程序存在漏洞,界面无法更改服务器IP等参数,暂时由罗宾森售后用烧写器改参数并逐个上线。罗宾森尽快修改。【优先级:高】
334 -2、桩目前无法将VIN上传后台,影响充电记录,无法知道哪些车辆进行了充电,罗宾森尽快修改。【优先级:高】
335 -3、车牌号、vin、集团/企业部门 三者之间的关系录入系统。【优先级:高,由施工和may处理】
336 -4、桩对接平台之刷卡功能。【优先级:中,需罗宾森支持】
168 +
1573633992288-441.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.Chinyee
Size
... ... @@ -1,1 +1,0 @@
1 -29.4 KB
Content
1575445987388-997.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.yuandong
Size
... ... @@ -1,1 +1,0 @@
1 -152.3 KB
Content
1578900456181-994.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.yuandong
Size
... ... @@ -1,1 +1,0 @@
1 -207.6 KB
Content
罗宾森_20191112001934329341问题排查.log
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ShiChuck
Size
... ... @@ -1,1 +1,0 @@
1 -1.2 KB
Content
... ... @@ -1,40 +1,0 @@
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、这时充电桩开始充电...