作者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