作者JJLi ()
看板Road
标题Re: [问题] 重复扣款的问题?
时间Wed Jan 8 18:45:10 2014
上百笔扣款错误 远通坦承 上路前未检出风险
http://news.chinatimes.com/focus/11050105/112014010800634.html
国道计程收费爆发重复扣款乱象,衍生远通电收及高公局在计程收费上路前的系统
验证有未检出的扣款风险。远通电收坦承,3、4日总计有上百笔资讯未被後端检核系统检
出而出现错误,昨晚10时之前都已依最後检核结果修正。
高公局:eTag需调校
交通部高公局表示,eTag上路初期交易笔数较多,系统需进行调校。
国道1号三重-台北北上路段、国道3号木栅-南港系统北上路段的ETC感应门架,
在计程上路後皆出现重复扣款情形,令用路人气愤。远通电收发言人周世惠指出,远通後
端系统在国道计次阶段就设置交易检核机制,能过滤重覆扣款的款项,出帐前再依最後结
果扣款。但3、4日因检核系统进行调校,导致部分款项未汇入,昨已立即修正。
天线接近 重覆扣款
针对同辆车在台北-圆山间同时被北上、南下门架扣款,远通表示,该路段南北门
架距离较近,清查发现2日到6日共3笔南北重复扣款资讯,已调整门架上天线感应位置,
并退还扣款。
还有民众反应帐户储值後,查询余额却归零。远通表示,车主可能在尚未入帐时查
询或连线状况较差,3日之後已恢复正常。
远通交易资讯显示,4日当天有南下车辆竟在17分钟内向北「瞬间移动」46公里并
遭扣款。周世惠指出,遭扣款车辆(A车)原为无eTag的全民体验方案用户,同意成为
eTag用户後,却将新取得的eTag放在家中另一台已有eTag的车辆(B车)上。
eTag移用 多扣不退
本月4日,两辆车都在国道行驶,上午9时20分一车由竹北南下新竹,另一车9时37
分由林口到桃园,因其中一车是透过摄影功能扣款,另一车则被以新eTag(属於A车)扣
款,形成同一车籍飘移重复扣款情形。
远通电收呼吁,一台车只能安装一个eTag,请车主不要将自车eTag放在别人车上,
否则後方检核机制无法过滤,将导致重复扣款,且这将被认定为车主个人行为,远通将不
会把多扣的通行费补给他。
-----以下是新闻评论.
有些系统错误本来就是不上路不扣款就不会知道的。
在懿晴的这篇报导里面提到,因为系统性错误所以前两天有上百件检核问题出现。
就先前的记录已经知道国道上路车流量是 100-150万辆/日
平均每部车
『推测』会通过5-10个交流道区间。
故每日的数据资料以低标推测应该会有500万件。
其中出错的件数是每日50-100件的情况。
则代表在前两天系统未修正前,远通的出错率是
低於 0.5/10000
万分之零点五
在这里我们就先不考虑etc上路的这些天车流量是比平常『大』还是『小』了…
大家可以思考看看,这是否是一个合理的错误率。
PS:只要十笔错误中有一笔跑去找媒体、立委爆料,(代表有十多笔大投诉)
立法院和媒体就会像现在一样对远通的评价非常低落了。
当然远通的查询系统独厚etag也是个问题,
没贴etag查明细要跑分店+付费…颇糟XD
专线小姐被给予回答问题的权限也不足(许多问题都要求助後线)
也难怪现在120个专线会被挤的水泄不通…
就算原本没问题的人也会因为不信任感而跑去『求助』了。
※ 引述《smartnick (司马特尼克)》之铭言:
: 我比较好奇的是,在计程收费前ETC不是已经测试一阵子了吗?
: 那段时间除虫除不完吗?
: 另外RFID理论上应该不是可见光的波长,所以闪蓝光应该是为了拍摄车牌而建立
: (如果有错请指教)
: 但现在看起来,不论是否有贴etag都会闪蓝光,想请问有人知道以後会改善吗?
: 如果贴和不贴都要拍摄车牌,真的很难理解那干嘛贴etag orz
: 这篇希望讨论技术层面的问题,希望有神人可以解答,谢谢
蓝光不是『闪』,而是长时间打灯来为『摄影』『录影』备援系统补光照车牌用。
在一开始时是白光,但满意度太低(太剌人)就改使用蓝光了。
基本上这个问题无解,除非彻底改变车牌的设计(苦笑)
再强调一次,车牌录影与摄影是『备援系统』,精准度绝对无法和感应线圈相比。
实际上前三日的系统性错误也反应了这点,etag的错误是多扣,备援系统是…少扣。
所以备援系统做了两个以外,高公局也极端积极的鼓励etag的设置。
应该不会有人希望自已应该收到的维护费有太多短收吧。
: ※ 引述《Georgeliu (开始混日子)》之铭言:
: : 这主要是因为etag的感应范围其实蛮大的,
: : 所以运气不好除了被南下的框架感应到外,也被北上的框架感应到,
: : 造成同时南北向都有感应到的情况。
: : 至於重复扣款这个我个人比较倾向是程式设计不良,
: : RFID的原理是感应框架持续放出电磁波(无线电波),
: : 当车上的etag接收到无线电波时内部线圈会产生电流,
: : 然後靠着这个电流启动etag内部的晶片再回传讯息给感应框架。
: : 一但电磁波受到外部环境的干扰,很可能就会出现重复感应的问题,
: : 正常来说远通的伺服器应该要有内建的判断机制,
: : 将这种显而易见的重复扣款给自动剔除掉,
: : 例如10秒内同一感应框架感应扣款的次数最多只能1次,
: : 超过1次的全部自动更改为1次,这样帐单秀出来就不会有重复扣款的问题,
: : 只是以现状来说,远通跟本就没准备好。
总之,再慢慢观察吧(苦笑)
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 111.252.171.15
1F:推 gmoz:很可惜他有些错误是系统不上线也会知道的XD 01/08 19:12
2F:→ gmoz:瞬间移动那个说得过去 车主自己天兵,帐户系统跟客服後援就 01/08 19:13
3F:→ gmoz:弄得很不好 01/08 19:13
4F:→ gmoz:更正,帐务系统 01/08 19:14
5F:推 gmoz:不过依我的观点 车牌录影是辅助系统并非备援系统就是了 QQ 01/08 19:17
6F:嘘 ngi:板主你是够了没 又在那边说这些五四三 还知道客服挤爆是被"不 01/08 19:24
7F:→ ngi:信任感" 你是神吗? 另外 客服以前就很难打了 01/08 19:25
8F:→ JJLi:楼上,那一段一整个是推测语气呀,当然是五四三呀XDDD 01/08 19:27
9F:→ JJLi:实际上怎样我如果知道的话就不会在这里推敲了(苦笑 01/08 19:27
10F:→ ngi:件数又是哪来的资料 口说无凭 门架好可以测的时间一大堆 01/08 19:27
11F:→ JJLi:件数资料 -- 详见新闻内文 -- 远通坦承,三、四日…Blabla 01/08 19:29
12F:→ ngi:挺也不要挺的这麽难看好吗 会多申请帐号去看明细导致错误爆出 01/08 19:30
13F:→ ngi:来的人已经是少之又少的少数了 件数最好是可以这样推断 01/08 19:31
14F:→ ngi:连"对远通的评价低落"都能用没根据的件数推断在那边说的好像受 01/08 19:33
15F:→ ngi:委屈 板主一直发这种不中肯的言论对吗? 之前私信就提醒过你了 01/08 19:33
16F:→ hateOnas:我昨天打客服 也打1968克服 01/08 19:35
17F:推 ngi:新闻就一堆民众被某局骗的以为没eTag不能上高速公路 原来那些 01/08 19:36
18F:→ ngi:错误案例都刚好多去申请帐号看明细 刚好看到错误 刚好po上m01 01/08 19:37
19F:推 canandmap:都说是推测了,怎麽还有人当真?XD 01/08 19:39
20F:→ ngi:"可以思考看看 错误率是否合理?" 推断就有问题了还在那误导-.- 01/08 19:39
21F:推 gmoz:各式观点评论本来就会有 无须如此动肝火啦@@ 01/08 19:40
22F:推 canandmap:要不然请某n自己调查看看J板主所言是否属实~口说无凭嘛~ 01/08 19:42
23F:推 ngi:我前面对etag还正常推文回覆 但看到身为板主偏颇装正经实在火 01/08 19:48
24F:推 canandmap:你对板主的推论及逻辑有质疑,何不如直接回文反驳,让 01/08 19:50
25F:→ canandmap:大家评评理是不是比较有效率? 01/08 19:50
26F:→ canandmap:结果一开场就呛板主讲五四三,又炮板主不要挺这麽难看 01/08 19:52
27F:→ canandmap:然後还说板主推断有问题,重点是哪个地方有问题? 01/08 19:52
28F:→ JJLi:有失公正哪…也对,这样的文章的确不该用这个帐号来发(苦笑 01/08 20:04
29F:→ JJLi:失礼了。 01/08 20:05
30F:推 kutkin:我认为只要不是用板主身分去针对立场不同的板友炮击 01/08 20:13
31F:→ kutkin:对於新闻有评论,我是觉得没有用到实质影响力啦 01/08 20:13
32F:推 xiaowei:与帐号无关吧,板主也是板友,只要不是以权势逼迫他人接受 01/08 20:14
33F:→ xiaowei:观点,有点立场那又何妨呢? 01/08 20:14
34F:→ pfry19855:哈哈这样的话JJ不是承认自己有分身帐号了XDDD 01/08 20:17
35F:→ JJLi:可是几年没用了耶XDD 刚试密码好像试不进去了怎麽办(爆 01/08 20:51
36F:推 ji394xu3:每日大约会有1400多万笔资料 假设出错笔数为100件/天 出 01/08 21:03
37F:→ ji394xu3:错率大约十四万分之一 01/08 21:03
39F:→ ji394xu3:天有1400万次以上交易量 ... 01/08 21:05
40F:→ ji394xu3:十四万分之一实际上要比万分之零点五又更小一点了... 01/08 21:06
41F:推 YiShenHsieh:这种错误不该发生的 公车电子票证有发生这种错吗? 01/08 21:22
42F:推 akway:捷运两百万人次/日票证表示: 01/08 21:41
43F:推 akway:说实在的 以前经过远通门市看他们都闲闲的 这阵子每天都大爆 01/08 21:44
44F:→ akway:满 真是可怜基层服务人员 XD 01/08 21:44
45F:→ gmoz:重点不在错误率 多低都一样 很多能避免的都没考量到 01/08 21:57
46F:→ gmoz:拿网页主机连基本的权限都没改 被人目录遍历攻击 我看这下还 01/08 21:58
47F:→ gmoz:需要re-shadow 01/08 21:59
48F:→ gmoz:这种程式写死不太会变动的东西 不能用机率来看 除非像车牌辨 01/08 22:00
49F:→ gmoz:识那种OCR还比较可以拿机率来说 01/08 22:01
50F:推 chienming40:错误率不是重点.对用路人来说管你一天几千万笔交易.对 01/08 23:51
51F:→ chienming40:他都是当天的第一次错误交易 01/08 23:52
52F:→ parislove3:不认同备援系统这点 三方案中包含VTP+预储 很明显是正 01/09 00:21
53F:→ parislove3:规方案 01/09 00:21
54F:推 traystien:全面换新牌才能解决OCR的问题 01/09 00:34
55F:→ traystien:旧牌还有辨识问题,但etag同时被两方向门架扣到有点... 01/09 00:35
56F:→ parislove3:没拆的eTag放後座也被扣到 真是奇葩 01/09 01:05
57F:推 ek252:YiShenHsieh大 每天也都有公车电子票证会出现纠纷 01/09 07:40
58F:推 DDJJ1069:chienming40大 错误率当然是重点 全世界去那儿找100%不会 01/09 07:43
59F:→ DDJJ1069:有交易错误的电子收费系统? 01/09 07:43
60F:→ DDJJ1069:说难听点,就连"人工"收费的便利超商店员找错了70几元都要 01/09 07:44
61F:→ DDJJ1069:被莫名其妙的5位流氓痛殴了.... 01/09 07:44
62F:推 chicagoboy:gmoz大跟chienming40大 错误率不是重点? 那套系统敢说 01/09 07:49
63F:→ chicagoboy:自己一定"零错误" 那开发那套系统的公司早就发到天边 01/09 07:49
64F:推 gmoz:举例来说 我跟你说我的计算机按1万次 1+1 只有1次会变成2 01/09 10:49
65F:→ gmoz:跟 我的计算机的按键 按一万次才会有一次没反应 的差别一样 01/09 10:49
67F:→ gmoz:网页又有很明确可以避免的漏洞出来了XD... 01/09 10:51
68F:→ neo718:计算机按1+1本来就会显示2阿,你按一万次只出现1次2? 01/09 10:51
69F:→ gmoz:错误率你要看套在什麽"类型"的系统上面 拿来说才有意义 01/09 10:51
70F:→ gmoz:更正 按1万次1+1只有1次会不是2 01/09 10:51
71F:→ neo718:假设同样是发生系统错误,但是用不同的情况来看: 01/09 10:57
72F:→ neo718:(1)同一辆小客车,从北往南下方向行驶,被南下感应器侦测两次 01/09 10:58
73F:→ gmoz:若演算法单纯 输入什麽就要输出什麽 而不存在"机率"这东西 01/09 10:58
74F:→ neo718:(2)同一辆小客车,从北往南下行驶,经过感应框架时, 01/09 10:59
75F:→ neo718:被南下与北上的感应器同时计数(等於两方向都感应计算) 01/09 11:00
76F:推 chicagoboy:gmoz大 你举的计算机例子根本完全失败... 01/09 11:00
77F:→ neo718:(3)一浪小客车经过南下台南的感应框架时,被林口北上感应架 01/09 11:01
78F:→ neo718:侦测到经过该收费框架. 01/09 11:02
79F:→ neo718:若以上三者出线的机率都是万分之一或十万分之一, 01/09 11:02
80F:→ neo718:但是这背後代表的系统错误/出错严重程度,会是一样吗? 01/09 11:03
81F:→ neo718:(补充:第3例是这几天已经发生过的实例,不是凭空捏造想像) 01/09 11:04
82F:→ gmoz:1侦测两次没问题 问题在於写进DB(或帐务DB)是否两次 01/09 11:04
83F:→ gmoz:2.同1 01/09 11:04
84F:→ gmoz:3. 实例是车牌与ETAG分开 这与架构流程以及防呆有关 01/09 11:05
85F:→ gmoz:计算机例子在於1+1!=2这种东西是根本不该出错的 按键则可 01/09 11:06
87F:→ gmoz:当然要拿整体出包率来看 的确数字很漂亮 但有好几则是可避免 01/09 11:07
88F:→ neo718:远通电收:重复交易是eTag必须面对的宿命 01/09 11:07
89F:→ gmoz:那则新闻我昨天分享给宅宅工程师如果 大家都笑得很开心 01/09 11:08
90F:→ gmoz: 如我的朋友们 01/09 11:08
91F:→ neo718:如果改用电脑侦测收费会重复计算是无可避免的宿命, 01/09 11:11
92F:→ neo718:那德国高速公路怎麽没有这情况? 远通这阵子就是一直找藉口. 01/09 11:12
93F:→ neo718:前几天看到介绍德国高速公路收费时,他们连里程数都不敢马虎 01/09 11:13
94F:→ neo718:全程用卫星定位GPS精准计算车辆行驶里程数, 01/09 11:14
95F:→ neo718:不像台湾在国道改用电子收费後,高工局还窜改标示里程数. 01/09 11:15
96F:→ gmoz:那则新闻的笑点在两个地方 1.今天才知道RFID的特性? 01/09 11:22
97F:→ gmoz:2.程式过滤随便举都好几种胜利宝剑帮你断开连结! 解开宿命 01/09 11:23
98F:→ gmoz:感觉是系统规格没有订得很好 整合测试也没有确实 01/09 11:23
99F:推 gmoz:话说她怎麽会说是eTag 红外线@@? 是记者笔误还是他口误 01/09 11:26
100F:→ pfry19855:德国卫星定位计程收费VPS在2005年就宣告失败了... 01/09 11:41
101F:→ pfry19855:就算是2014年德国准备要重新启动的高速公路收费计画也没 01/09 11:54
102F:→ pfry19855:有要用即时定位技术,而是采类似汽燃费的定额预付制。 01/09 11:55
103F:推 chienming40:对"用路人"来说."他"可能只是经过一个门架就出错了.谁 01/09 12:50
104F:→ chienming40:还管你远通一天的交易次数有几千万次. 01/09 12:52
105F:→ ji394xu3:一套系统又不是只服务"他"这一个用路人而已 01/09 13:02
106F:→ ji394xu3:悠游卡每天都有交易纠纷 不是早就该.... 01/09 13:03
107F:推 ottokang:拿计算机比是在比啥?这是无线RFID,还有车速的问题 01/09 16:31
108F:→ ottokang:在这些条件下你可以搞到100%完全不会失误 01/09 16:32
109F:→ ottokang:那就准备输出技术到国外好了 01/09 16:33
110F:→ ottokang:台湾就是这样,对於合理的错误修正都不能容忍 01/09 16:33
111F:→ ottokang:以为这样就是专家、就是监督,实际上就是理盲啊 01/09 16:34
112F:推 gmoz:重复感应这种基本的交叉覆盖的排除 其实跟计算机的1+1差不多 01/09 16:49
113F:→ gmoz:因为你高速公路车子移动方向就是那样 如果天天收费站那边出 01/09 16:50
114F:→ gmoz:车祸 或是车子会横向飞来飞去除外XDDD 01/09 16:50
115F:→ gmoz:我推文的重点其实一直都是针对能避免却未避免的部分来说 01/09 16:52
116F:→ gmoz:这个叫合理 工程师们都笑了www 01/09 16:52
117F:→ gmoz:RFID本身的感应失误是算在计算机的按钮那种类型 重复扣款则否 01/09 16:56