文档更改颂盛
在2020/12/25 14:13上被chinyee he修改
修改评论 该版本没有评论
Summary
-
Page properties (2 modified, 0 added, 0 removed)
-
Attachments (0 modified, 0 added, 8 removed)
Details
- Page properties
-
- 文档作者
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. yuandong1 +XWiki.Chinyee - Content
-
... ... @@ -2,269 +2,24 @@ 2 2 {{toc/}} 3 3 {{/box}} 4 4 5 -= gdss_case#10_20200217 = 6 - 7 -问题描述:http:~/~/cloud.linghuchongtech.com/DynamicAdmin2/login.html 8 - 9 -账号:ssxny 10 -吴小英说这个账号无法登录。 11 - 12 - 13 -~-~-跟踪 14 - 15 -【YD】:我试了下该账号出现了“同时登陆用户数量超过限制”的提示。**与之前金凯瑞jkr_case#28_20200211属于同样的问题,故以同样的方式处理。** 16 -1、他这个问题之前都提过几次。他的账号有同时登陆数量15的限制 17 - 18 - 19 -**客户不按规则操作,故给他同时登录次数设到100,避免再出现** 20 - 21 -~-~-解决 22 - 23 -状态(☑表示选定 ): ☑已解决 | 处理中 | 暂搁置 24 -售后(跟单)工程师 YD 25 - 26 -= gdss_case#9_20200117 = 27 - 28 -(% class="wikigeneratedid" %) 29 -问题描述:截止到今 颂盛未处理异常账单统计 30 - 31 -(% class="box infomessage" %) 32 -((( 33 -提供一份数据:1)未处理异常账单统计。 34 - 35 -1)异常账单统计:下表为 **2019年3月到至今**之未处理异常代码统计 36 - 37 -|**异常代码\统计时间段**|**201903-至今** 38 -|**1-账单丢失**|261 39 -|((( 40 -**3- 时间异常** 41 -)))|219 42 -|**11-电量丢失**|294 43 -|**2-账单丢失(设备离线)**|7 44 -|**3,4(充电电量异常),5(充电时长异常),8(充电电量与平台不符),9(充电时长与平台不符)**|1 45 -|**3,5,7(充电时间重叠),8,9**|2 46 -|**3,5,8,9**|1 47 -|**3,6(占桩时长异常)**|18 48 -|**3,8**|273 49 -|**3,8,6**|115 50 -|**3,8,9**|3 51 -|**4,8,6**|1 52 -|**6**|1291 53 -|**7**|15 54 -|**7,8**|3 55 -|**7,8,9**|20 56 -|**7,8,9,6**|44 57 -|**7,9,6**|15 58 -|**8**|77854 59 -|**8,6**|32902 60 -|**8,9**|536 61 -|**8,9,6**|1347 62 -|**9**|36 63 -|**9,6**|33 64 -|**合计**|115291 65 -))) 66 - 67 -~-~-解决: 68 -状态(☑表示选定 ): ☑ 已解决 | 处理中 | 暂搁置 69 - 70 -数据统计人:Chinyee 71 - 72 - 73 -= gdss_case#8_20200115 = 74 - 75 -问题描述:旧平台 76 -1.吴小英说他误修复了几张异常账单,希望把那几张单改回异常状态。 77 - 78 -2.修复后报表里多了这几张单,颂盛的客人那边会出现前后报表不一致的情况。他想避免这情况 79 - 80 -3.旧平台上他反应未修复的账单也能在报表看到20200108165713818444 20200111022016826908 这两个账单是没修复过的 81 - 82 -~-~-跟踪 83 - 84 -【YD】: 85 - 86 -1)2)已修复的,我们不能随意修改客户数据,如果客人问起来您需要向他们解释。 87 -3)颂盛这边一直都是配置成允许异常账单先结算扣款,后续人工修复再补扣,所以报表能看到 88 -【shi】:1、下图配置的意思是允许异常账单先结算扣款,后续人工修复再补扣。 89 -2、一些客户不能及时修复账单,是用了先结算, bo2和bo1的机制是一样的。 90 -3、建议客户及时处理异常账单,特别是公交周期结算前 是必须处理完的。 91 -[[image:1579061130998-533.png]] 92 - 93 - 94 - 95 -~-~-解决: 96 -状态(√表示选定 ): 已解决 | 处理中 | 暂搁置 97 - 98 -售后(跟单)工程师:施文俊 YD 99 - 100 -= gdss_case#7_20200113 = 101 - 102 -问题描述: 103 - 104 -颂盛旧系统平台 105 -日期:2020-01-13 106 -桩站名称:颂盛站点 107 -手机号: 108 -订单号:20200113131916994301、20200113130454355822、20200113130336691650、20200113130240664036、20200113125312202217、20200113125311761057、20200113125203914204、20200113124854037470、20200113124637079267、20200113124544419307、20200113123331114379、20200113123029340160、20200113122916302241、20200113122040542106、20200113120748494182、20200113120300119547、20200113115846103652、20200113115828334527、20200113114219467743、20200113113813352135 109 -充电桩号:44011300040000200055、、44011300040000250003、44011300040000240001、44011300040000210006、44011300040000200085、44011300040000200054、44011300040000210005、44011300040000200083、44011300040000240002、44011300040000200053、44011300040000200093 110 -充电枪号: 111 -充电时间: 112 -结束时间: 113 -现场网络连接状态:正常 114 - 异常状态:充电电量与平台不符 115 -问题描述:充电电量与平台不符,请帮忙查看一下是什么原因,见下图: 116 - 117 -[[image:1578900456181-994.png||height="469" width="942"]] 118 - 119 -~-~-跟踪 120 - 121 -【YD】:转研发确认是否与gdss_case#6_20191204的原因一致。 122 -【令技术】:以上账单中出现的“充电电量与平台不符”的异常, 都是由于充电桩在充电前上送心跳的电表总读数均为0, 启动充电后,电表总读数变为一个较大的值 造成的 计算异常。 123 - 124 -~-~-解决: 125 -状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置 126 - 127 -售后(跟单)工程师:施文俊 YD 128 - 129 -= gdss_case#6_20191204 = 130 - 131 -广州颂盛旧系统平台 132 -日期:2019-12-04 133 -桩站名称:塘坑站点、大岗站点、桥南站点、 134 -手机号: 135 -订单号: 136 -充电桩号: 137 -充电枪号: 138 -时间:2019年11月份 139 -\\现场网络连接状态:正常 140 - 异常状态:金额、峰、平、谷值都为0 141 -问题描述:今天早上接到客户的反应颂盛的三个站点有几条充电日报表金额、峰、平、谷值都为0,见表格下: 142 - 143 -20191108112557047049 144 -20191109045929266559 145 -20191112002225771301 146 -20191116000001501830 147 -20191125001902046919 148 -20191127001635518809 149 -20191106044333115970 150 -20191109000104273153 151 - 152 -~-~-跟踪 153 - 154 -【YD】:这些单都为“账单丢失”,但手动修正里有部分单的修正电量过大。 155 - 156 -【niewei】20191205 出现几万度电的情况, 是由于罗宾森桩的电表读数异常造成的。 需要人工处理。 157 - 158 -[[image:1575445987388-997.png||height="365" width="842"]] 159 - 160 -~-~-解决: 161 -状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置 162 - 163 -售后(跟单)工程师:施文俊 YD 164 - 165 - 166 -= gdss_case#5_201911113 = 167 - 168 -广州颂盛旧系统充电平台 169 - 170 -日期:2019-11-13 171 -桩站名称: 172 -手机号: 173 -订单号:20191108112557047049/20191109000104273153/20191109045929266559 174 -充电桩号: 175 -充电枪号: 176 -开始充电时间: 177 -现场网络连接状态:正常 178 -异常状态: 179 -问题描述:现在广州颂盛大岗站、塘坑站出现峰平谷值为零的现象 180 - 181 -~-~-跟踪 182 - 183 -【令】:排查结果如下,都是充电桩上送的电表读数异常所致。颂盛的桩是 “罗宾森”桩, 这个电表读数异常的问题,还存在。 184 - 185 -[[image:1573633992288-441.png]] 186 - 187 -~-~-解决: 188 -状态(√表示选定 ): √ 已解决 | 处理中 | 暂搁置 189 - 190 -售后(跟单)工程师:施文俊 何倩怡 191 - 192 - 193 -= gdss_case#6_20191112 = 194 - 195 -广州颂盛旧系统平台 196 -日期:2019-11-12 197 -桩站名称:广州颂盛桥南充电站 198 -手机号: 199 -订单号:20191112001934329341 200 -充电桩号:44011300040000200061 201 -充电枪号: 202 -开始充电时间:2019-11-12 00:23:38 203 -结束时间:2019-11-12 03:50:36 204 -现场网络连接状态:正常 205 - 异常状态:充电量与平台不符 206 - 207 -[[image:1573546978385-211.png||height="334" width="705"]] 208 - 209 -~-~-跟踪 210 - 211 -【令】:已转研发 212 -【shi】: 罗宾森桩的问题看来是比较多啊。见附件 [[attach:罗宾森_20191112001934329341问题排查.log||target="_blank"]],罗宾森解释是RS485丢包造成的。 目前暂时由后台人工处理了, 用设备账单来计费。 213 -to 金凯瑞许总: 214 -请关注罗宾森桩程序目前的问题。 215 -联想到贵司伙伴即将在深圳运营,不禁有些担忧。按照我的经验,深圳市社会车辆 充电业务量的数量级是其他城市几倍,用户对充电数据精准性不是公交充电能比的(仅月底看一次数据。) 216 -附件是我司技术对问题账单分析,我按照通俗易懂方式给您解释如下: 217 -1)背景知识:计算机需要按照约定的协议严格执行协议流程。 218 -2)类比举例: 219 -吃饭需要5步,即:1,2,3,4,5。 220 -小明实际吃饭步骤:1,3,4,5 或 1,3,2,4,5 或 1,2,2,2,3,4,5 等类似不按约定协议执行。 221 -3)因为第2项的原因,充电桩在一些情况下(蒙混过关)看来是完成充电了,因为运营环境的复杂,实际上会很大概率出现各种无法预期的异常。 222 -4)第2项 这个问题 从第一个罗宾森桩投入运营上线至今似乎一直存在,未彻底解决。看如何彻底解决。 223 -5)如果 大家认同 运营稳定排第一位。 所谓 RS485 丢包造成,是否可以更换 相应的模块配件。 224 - 225 -~-~-解决: 226 -状态(√表示选定 ): 已解决 | 处理中 | 暂搁置 227 - 228 -售后(跟单)工程师:施文俊 YD 229 - 230 230 = gdss_case#5_20191031 = 231 231 232 232 233 233 问题描述:这怎么修复只充了34分钟就要244.40元了 234 234 235 -账单号:20191024144331381526 236 - 237 237 [[image:1572491525002-420.png||height="381" width="766"]] 238 238 239 239 240 -~-~- 跟踪13 +~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-- 241 241 242 -[[image:1572492802252-387.png||height="180" width="783"]] 243 -【chinyee】: 244 -该账单号的充电心跳,其中: 245 -1、充电数据是线性增长,未察觉异常 246 -2、2019-10-24 15:10:28到15:17:30之间没有心跳上传,且15:17:30当前状态为8充电异常。 247 -【shi】:异常账单中查到 账单丢失,平台估算电量 128.63度,超正常值。 需转研发分析。 248 -【令狐充技术】: 249 - 250 -(% class="box infomessage" %) 251 -((( 252 -1、该充电桩在充电过程中发生离线, 所有有一段时间没有心跳; 253 -2、平台估算电量为128.63度, 是因为该充电桩在本次充电之前上传的电表总读数为0所致, 所以这个估算值是不准确的。 254 -开始充电后,电表读数直接跳到92.27 255 -估计这个才是实际值 256 -之后充电中离线了一段时间,恢复后状态已经变成空闲 257 -但是账单一直没上传 258 -))) 259 - 260 -【shi】: 疑似电桩老问题未解决,需客户协调罗宾森 厂家 排查解决。 261 - 262 - 263 263 ~-~-解决: 264 264 状态(√表示选定 ): 已解决 | √ 处理中 | 暂搁置 265 265 266 266 售后(跟单)工程师:施文俊 何倩怡 267 267 20 +(% class="wikigeneratedid" %) 21 += = 22 + 268 268 = gdss_case#4_20191028 = 269 269 270 270 广州颂盛旧系统充电平台 ... ... @@ -390,21 +390,4 @@ 390 390 391 391 售后(跟单)工程师:施文俊 392 392 393 - 394 -~#~##番禺项目汇报-20180724 395 -人员: 396 - 罗宾森售后 397 - 金凯瑞工程人员、项目经理、平台管理员 398 - 令狐充平台工程师 399 - 番禺场站公交负责人、运维人员 400 -\\阶段性成果: 401 - a、介绍平台功能和基本使用情况。客户运维、金凯瑞平台运维和令狐充运维 建微信群 计划初期对运营进行支撑和维护。 402 - b、目前支持站点密码为场站之车辆进行充电。 403 - c、少量电桩完成平台接入,并通过公交充电测试。其余待网络、电力设备就绪后逐个接入平台。 404 - 405 - 406 -联调之问题汇总: 407 -1、桩的程序存在漏洞,界面无法更改服务器IP等参数,暂时由罗宾森售后用烧写器改参数并逐个上线。罗宾森尽快修改。【优先级:高】 408 -2、桩目前无法将VIN上传后台,影响充电记录,无法知道哪些车辆进行了充电,罗宾森尽快修改。【优先级:高】 409 -3、车牌号、vin、集团/企业部门 三者之间的关系录入系统。【优先级:高,由施工和may处理】 410 -4、桩对接平台之刷卡功能。【优先级:中,需罗宾森支持】 148 +
- 1572492802252-387.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.Chinyee - Size
-
... ... @@ -1,1 +1,0 @@ 1 -117.2 KB - Content
- 1572506227600-542.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.ShiChuck - Size
-
... ... @@ -1,1 +1,0 @@ 1 -145.4 KB - Content
- 1573546978385-211.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.yuandong - Size
-
... ... @@ -1,1 +1,0 @@ 1 -191.9 KB - Content
- 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
- 1579061130998-533.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.ShiChuck - Size
-
... ... @@ -1,1 +1,0 @@ 1 -51.9 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、这时充电桩开始充电...